The record keys in their video, ('partner_id'), are nice human-readable text because they imported them that way. Those records were not entered into OpenERP by an end-user.

Every database record requires an identification key that is unique within that data table. OpenERP creates those using database sequential number sources called sequences. However, products like OpenERP benefit hugely from interconnectivity, and therefore have also to trust to unique identifiers supplied from outside.

You will find an extremely long and narrow data table called ir_model_data (model: ir.model.data):

select id, res_id, name, module, model from ir_model_data where name = 'FredBlogs';
    id  | res_id |    name   | module |    model
  ------+--------+-----------+--------+-------------
   8349 |      6 | FredBlogs |        | res.partner
  (1 row)

That query shows that a mapping was recorded for the res.partner data table at row 8349 in the table ir_model_data. The res.partner table primary key 6 is mapped to an external key 'FredBlogs', which was provided at the time the record was imported.

When it is time to export that data, the external id is provided, rather than the internal one. If no external id has been provided then an ugly generic one is generated (such as: "__export__.sale_order_1884" and "__export__.sale_order_1891").

Is there a better / easier PostgreSQL export tool I could use?

Once I got comfortable with working with the conceptual structure outlined above I ceased to view working with the database directly as a suitable option! SQL is very "rigid" and would require constant manual adaptation to changes wrought by future subclassing and extending of the modules whose data the tables record. It's really important to work through the Object Relational Mapping (ORM) layer!

Meanwhile . . . I agree that loading the database, one model at a time, using the import dialog is excessively labour intensive, and far from ideal, hence my work on my little GData OpenERP Data Pump.