Re: pg_dump: use ALTER TABLE for PKs - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: pg_dump: use ALTER TABLE for PKs
Date
Msg-id GNELIHDDFBOCMGBFGEFOIEHJCBAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Re: pg_dump: use ALTER TABLE for PKs  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
The behaviour you illustrate below does not exist and therefore is not a
problem:

test=# create table parent(f1 int primary key);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 'parent_pkey'
for t
able 'parent'
CREATE
test=# create table child(f2 int) inherits (parent);
CREATE
test=# \d parent       Table "parent"Column |  Type   | Modifiers
--------+---------+-----------f1     | integer | not null
Primary key: parent_pkey

test=# \d child       Table "child"Column |  Type   | Modifiers
--------+---------+-----------f1     | integer | not nullf2     | integer |


Chris

> -----Original Message-----
> From: Philip Warner [mailto:pjw@rhyme.com.au]
> Sent: Wednesday, 20 February 2002 4:53 AM
> To: Neil Conway; pgsql-hackers@postgresql.org
> Cc: Christopher Kings-Lynne
> Subject: Re: [HACKERS] pg_dump: use ALTER TABLE for PKs
>
>
> 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
> put the PK (and, necessarily, FK) creation at the end of the data load:
>
>     CREATE TABLE PARENT(F1 INT);
>     CREATE TABLE CHILD(...) INHERIT PARENT
>
>     Load PARENT
>     Load CHILD
>
>     ALTER TABLE PARENT...PK
>     ALTER TABLE CHILD...PK
>
> This is a non-trivial issue since we also need to cater for:
>
>     CREATE TABLE PARENT(F1 INT);
>     CREATE TABLE CHILD1(...) INHERIT PARENT
>     ALTER TABLE PARENT...PK
>     CREATE TABLE CHILD2(...) INHERIT PARENT
>
> Which, at least historically, resulted in CHILD1 *not* having a
> PK. I would
> have built CVS and checked myself, but I'm relocating office (and servers)
> at the moment.
>
>
> ----------------------------------------------------------------
> Philip Warner                    |     __---_____
> Albatross Consulting Pty. Ltd.   |----/       -  \
> (A.B.N. 75 008 659 498)          |          /(@)   ______---_
> Tel: (+61) 0500 83 82 81         |                 _________  \
> Fax: (+61) 0500 83 82 82         |                 ___________ |
> Http://www.rhyme.com.au          |                /           \|
>                                  |    --________--
> PGP key available upon request,  |  /
> and from pgp5.ai.mit.edu:11371   |/
>



pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: alter table drop column status
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Re: SET NULL / SET NOT NULL