> I'm thinking about attacking pg_dump's lack of knowledge about using
> dependencies to determine a safe dump order. But if there's someone
> out there actively working on the problem, I don't want to tread on
> your toes ... anyone?
I've done a whole lot of _thinking_, but basically no _doing_, so go
right ahead :)
I may as well let you know my thoughts:
There are two levels (sort of) of dependency. The first is that whole
classes of objects can be dependent on whole other classes. eg.
databases depend on users, or ALL FK's can be dumped after ALL tables,
etc.. It would make the dump more readable if you dumped those definite
dependencies in that order, rather than shuffling everything up.
The second level of dependency is when a bunch of object types can
depend on each other. The current solution for that is to sort by OID,
but this fails when it is possible to add a dependency to an object
after it has been created.
eg:
- Adding a column (with a type) to a table
- All the CREATE OR REPLACE commands
- etc.
Hence, a full db wide topological sort might not be necessary.
Lastly, I presume it's possible to create a system of circular
dependencies (eg create or replace view), which really cannot be solved
without a system of 'shells', similar to that needed to dump types and
their i/o functions.
Views seem to be by far the nastiest object. They can be dependent on
almost everything in the database.
> Also, if you've got uncommitted patches for pg_dump, please let me know.
Yes, my 'COMMENT ON' mega patch in the queue contains dumping of
conversions and comments on a bunch of objects.
BTW, if you commit that patch - you might want to change my comment on
type patch to put the "" around "any", and change the results file
appropriately. I noticed I accidentally included that in the patch, and
was about to mention it.
CHris
