Re: pg_dump: use ALTER TABLE for PKs

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).

In response to

Responses

Browse pgsql-hackers by date

  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