Re: pg_dump: use ALTER TABLE for PKs
От | Stephan Szabo |
---|---|
Тема | Re: pg_dump: use ALTER TABLE for PKs |
Дата | |
Msg-id | 20020220075520.K836-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: pg_dump: use ALTER TABLE for PKs (Philip Warner <pjw@rhyme.com.au>) |
Список | pgsql-hackers |
On Wed, 20 Feb 2002, Philip Warner wrote: > At 14:05 19/02/02 -0800, Stephan Szabo wrote: > > > >Check constraints and not null I believe are inherited by default. > >But I just thought of a case that won't dump and restore the same as it > >was originally made because we support ONLY on alter table add constraint. > > > >create table z(a int); > >create table z2() inherits(z); > >alter table only z add constraint foo1 check(a>4); > > > >will make z have a constraint on a but not z2 and the check will get > >dumped as part of z's definition which will restore with z2 having > >the check. > > This brings to mind a couple of questions: > > 1. Do you have plans to support inhertiance of PK constraints? If you mean me personally, not in the short term. I don't think that pk over an inheritance tree means a copy of the constraint for each table either, so it's not quite the same as some of the other constraints. > 2. Does/will DROP CONSTRAINT support ONLY? Pretty sure it does. I also think it'll let you drop an inherited constraint from a child table which can get you into the same state as the create/alter above. Does dropping inherited constraints from children or allowing constraints to be added to only the parent table make sense? I only wonder because unless you're using only on the queries you'll see the rows in the children that violate the constraint which seems kinda odd to me.
В списке pgsql-hackers по дате отправления: