From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Rod Taylor" <rbt(at)zort(dot)ca>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Open 7.3 issues |
Date: | 2002-08-15 04:28:55 |
Message-ID: | 19787.1029385735@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> What about this.
> 1. Implement pg_get_foreignkey_def() or whatever
> 2. Adjust pg_dump to dump foreign keys using an ALTER statement
> 3. Back port the above to rel 7_2_2
> 4. Release a 7.2.2 version and ask that people upgrade to that version and
> do a dump before they upgrade to 7.3.
The trouble with this is that 7.2.2 would include a lot of rather poorly
tested code (code that has not even made it to CVS yet) ... and if
there's a problem in that code, it breaks dump files whether you are an
early upgrader to 7.3 or not.
I think that's likely to be a hard sell. The most we are likely to get
is to ask people to use the 7.3 pg_dump to dump their 7.2 server when
they are about to upgrade to 7.3 --- even that much is a difficult trick
for RPM users.
The other problem is that given a 7.2 system catalog setup, it's not
really any easier to reconstruct "this is a foreign key" on the server
side than it is to do it on the pg_dump side. So if we can figure out
how to do it at all, we might as well make pg_dump do the work instead
of insisting on a server update.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-08-15 04:43:58 | Re: contrib Makefiles |
Previous Message | Rod Taylor | 2002-08-15 04:25:12 | Re: Open 7.3 issues |