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 |/
