Re: pg_dump in 7.4

At 08:36 AM 13/11/2002 -0500, Tom Lane wrote:
>No, because that doesn't help for the plain-text-dump case.

Wrong. The way pg_dump does a plain-text dump is to do a fake restore. Same 
code. Which meand if make the restore work correctly and everything works.


>   I think we
>should solve the dependencies during pg_dump and output the objects in a
>safe order.

We should do this anyway, just to make the restorations quicker (as we do 
already).


>   pg_restore can keep its options for rearranging the order,
>but those should become vestigial, or at least only needed in bizarre
>cases.

Ordering is not the problem; it's allowing the user to dump a single table 
and associated type definitions that requires the

pg_dump really *must* dump dependency information. Then the dump/restore 
code can sort it appropriately.

The way the code works at the moment is:

- Dump definitions in any convenient order, creating an in-memory TOC.
- Sort the TOC entries appropriately (using code in pg_backup_archiver).
- Dump the definitions and data to file/stdout (using code in 
pg_backup_archiver).

We need is to replace the naieve quicksort with a more complex sorting system.

The suggestion of breaking items into create/alter etc is interesting - I 
assume you are thinking of function bodies? Or is there something else?



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/