From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, <pgsql-hackers(at)postgresql(dot)org>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Subject: | Re: pg_dump: use ALTER TABLE for PKs |
Date: | 2002-02-19 21:07:55 |
Message-ID: | 20020219130125.D89690-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 20 Feb 2002, Philip Warner wrote:
> At 21:26 18/02/02 -0500, Neil Conway wrote:
> >
> >Bruce suggested that this should get some code review, since a bug in
> >pg_dump would be bad news. Any comments would be welcome.
> >
>
> Part of the reason I did not implement this earlier was that ALTER
> TABLE...PK did not handle child tables 'properly' (for some arbitrary
> meaning of the word 'properly'). How have you covered:
>
> CREATE TABLE PARENT(F1 INT PRIMARY KEY);
> CREATE TABLE CHILD(...) INHERIT PARENT
>
> this should create a PK on CHILD; what does pg-dump and the ALTER TABLE
> implementation do? Not sure how it should work, but ultimately we need to
Unless it was changed between rc2 and release, the above type of
sequence does not end up with a primary key on child(f1).
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2002-02-19 21:33:43 | Re: [HACKERS] UTF-8 data migration problem in Postgresql 7.2 |
Previous Message | Tom Lane | 2002-02-19 21:06:09 | Re: Information about XLogWrite |