Re: [HACKERS] pg_dump table order

"Ross J. Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu> writes:
> Ah I think I just figured it out: it's that pesky object
> support, isn't it? In order to use a table (class) as a member (field)
> of another table, it has to exist first, and the only thing in the
> system table that ensures that is oid. Bummer. Hmm, it'd still be useful
> for comparision purposes, but it wouldn't gaurantee correct SQL scripts.
> Perhaps I'll just hack my local copy with an extra switch for "class
> name order output". Anyone else want it?

Better idea: make pg_dump smarter, so that it sorts the tables by name
as far as possible without breaking inheritance and membership
dependencies. It already retrieves the inheritance graph, and it could
certainly figure column-type dependencies too. I don't think anyone
would object to producing the output in a more meaningful order, so
I see no need for a switch if you can make this work.

I used to know enough about topological sorts to sketch how this ought
to work, but that was years ago :-(. I do see that the simplest
approach to a sort comparison function, "if a depends on b then say a>b,
else say result of comparing name(a) and name(b)", will not work because
it's not transitive.

regards, tom lane