Re: [HACKERS] pg_dump table order - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pg_dump table order
Date
Msg-id 9723.937233664@sss.pgh.pa.us
Whole thread Raw
In response to pg_dump table order  ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
Responses Re: [HACKERS] pg_dump table order  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.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


pgsql-hackers by date:

Previous
From: Leon
Date:
Subject: Re: [HACKERS] Status report: long-query-string changes
Next
From: Constantin Teodorescu
Date:
Subject: Re: [HACKERS] Re: pgaccess update for 6.5.2?