From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] pg_dump table order |
Date: | 1999-09-13 02:05:35 |
Message-ID: | 199909130205.WAA09513@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Hey hackers:
> I'vebeen using pg_dump in a typical three db setup: development,
> staging, and live. The output of pg_dump is ordered by oid, so as the
> db's histories diverge, the output does as well. That is, if identical
> tables get created in the development and staging dbs, for example, but
> in a different order, I can't us diff to test this. I was wondering if
> there is any reason why the order couldn't be by tablename, instead of
> oid, since the ordering of creation of sequences and types and such is
> taken care of.
>
> 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?
>
I thought someone already did that. It may be in 6.5.1.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-09-13 02:47:47 | Re: [HACKERS] Fixing Simms' vacuum problems] |
Previous Message | Ross J. Reedstrom | 1999-09-13 01:35:27 | Re: [HACKERS] pg_dump table order |