Re: pg_dump: use ALTER TABLE for PKs
От | Stephan Szabo |
---|---|
Тема | Re: pg_dump: use ALTER TABLE for PKs |
Дата | |
Msg-id | 20020219135628.I90505-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: pg_dump: use ALTER TABLE for PKs (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: pg_dump: use ALTER TABLE for PKs
|
Список | pgsql-hackers |
On Wed, 20 Feb 2002, Philip Warner wrote: > At 13:07 19/02/02 -0800, Stephan Szabo wrote: > >> > >> 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). > > Interesting, - that makes pg_dumps job easier. Are any constraints ever > inherited? 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.
В списке pgsql-hackers по дате отправления: