Skip site navigation (1) Skip section navigation (2)

Re: BUG #4291: Inheritance fails on column suppression

From: c(dot)duprez(at)libertysurf(dot)fr <c(dot)duprez(at)libertysurf(dot)fr>
To: tgl <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4291: Inheritance fails on column suppression
Date: 2008-07-11 12:33:22
Message-ID: K3UDJM$DFC734B7AF2EBFECE20A61CBD4D05FF6@aliceadsl.fr (view raw or flat)
Thread:
Lists: pgsql-bugs
Thank you very much for your answer.

In the documentation, the last lines of chapter 5.8 say :
" A parent table cannot be dropped while any of its children
remain. Neither can columns of child tables be dropped or
altered if they are inherited from any parent tables. If you
wish to remove a table and all of its descendants, one easy
way is to drop the parent table with the CASCADE option.

ALTER TABLE will propagate any changes in column data
definitions and check constraints down the inheritance
hierarchy. Again, dropping columns or constraints on parent
tables is only possible when using the CASCADE option. ALTER
TABLE follows the same rules for duplicate column merging
and rejection that apply during CREATE TABLE."

Reading this, I understand that using the CASCADE key word
in the alter synthax means that the child columns will be
dropped too. Especially reading the paragraph just before
this one, which says :

"Table inheritance is typically established when the child
table is created, using the INHERITS clause of the CREATE
TABLE statement. Alternatively, a table which is already
defined in a compatible way can have a new parent
relationship added, using the INHERIT variant of ALTER
TABLE. To do this the new child table must already include
columns with the same names and types as the columns of the
parent. It must also include check constraints with the same
names and check expressions as those of the parent.
Similarly an inheritance link can be removed from a child
using the NO INHERIT variant of ALTER TABLE. Dynamically
adding and removing inheritance links like this can be
useful when the inheritance relationship is being used for
table partitioning (see Section 5.9). "

Regards,

C. Duprez

---------- Initial Header -----------

From      : Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To          : "Duprez" <c(dot)duprez(at)libertysurf(dot)fr>
Cc          : pgsql-bugs(at)postgresql(dot)org
Date      : Thu, 10 Jul 2008 10:34:19 -0400
Subject : Re: [BUGS] BUG #4291: Inheritance fails on column
suppression

"Duprez" <c(dot)duprez(at)libertysurf(dot)fr> writes:
> Then, I remove th inheritance link by performing an ALTER
command :
> ALTER TABLE test2.point NO INHERIT test1.point;
> And then, I restablish the inheritance :
> ALTER TABLE test2.point INHERIT test1.point;
> The problem is that, if now I drop a column from the
parent table, the
> column remains in the child table, whereas the inheritance
is established :

This is not a bug.  Once the child was dis-inherited, all
its columns
became locally defined, and they'd stay that way on
re-inheritance.
(There is no memory in the system that would allow us to
determine that
the attislocal flag should be removed --- that is, we can't tell
this case from the case where column test2 was declared
locally in
the original child table definition.  It doesn't seem worth
adding
still more complexity to the column inheritance state just
to cover this.)

> According to the documentation, this should not be the case.

Please state where you think the documentation says that, so we
can fix it.

			regards, tom lane



---------------------- ALICE N°1 de la RELATION CLIENT 2008*--------------------
Découvrez vite l'offre exclusive ALICE BOX! En cliquant ici http://abonnement.aliceadsl.fr Offre soumise à conditions.*Source : TNS SOFRES / BEARING POINT. Secteur Fournisseur d.Accès Internet



pgsql-bugs by date

Next:From: Tom LaneDate: 2008-07-11 13:55:39
Subject: Re: BUG #4296: Server crashes by restoring database
Previous:From: Michal SzelagDate: 2008-07-11 08:42:40
Subject: BUG #4296: Server crashes by restoring database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group