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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
