Re: pg_dump: use ALTER TABLE for PKs

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 null
f2 | integer |

Chris

> -----Original Message-----
> From: Philip Warner [mailto:pjw(at)rhyme(dot)com(dot)au]
> Sent: Wednesday, 20 February 2002 4:53 AM
> To: Neil Conway; pgsql-hackers(at)postgresql(dot)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 |/
>