Re: pg_dump: use ALTER TABLE for PKs
От | Philip Warner |
---|---|
Тема | Re: pg_dump: use ALTER TABLE for PKs |
Дата | |
Msg-id | 3.0.5.32.20020220075304.039fd9b0@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | pg_dump: use ALTER TABLE for PKs (Neil Conway <nconway@klamath.dyndns.org>) |
Ответы |
Re: pg_dump: use ALTER TABLE for PKs
Re: pg_dump: use ALTER TABLE for PKs |
Список | pgsql-hackers |
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 по дате отправления: