buschmann@nidsa.net writes:
> It seems that the catalogs are screwed up when adding /deleting columns
> inderectly for inherited tables. This was tested under PG 9.6.3 and 10beta1
> under Windows x64.
I could not reproduce any such misbehavior from the details you gave.
Perhaps you could provide a self-contained example? (Ie, starting
from scratch, create and alter some tables to arrive at a bogus state.)
Note that it's not necessarily wrong for a column deleted from the parent
to still exist in a child; if the child had a local definition to start
with then it would still have one afterwards. For example,
create table p (f1 int, f2 int, f3 int);create table c (f2 int) inherits (p);-- you'll get some bleat about merging f2
withthe inherited columnalter table p drop column f2;alter table p drop column f3;-- c will now have f1 (inherited) and
f2(local), but not f3
But I can't think of a case where we should allow a column to exist
in a parent but not a child.
You might find it useful to examine pg_attribute.attislocal (does
column have a "local" definition?) and pg_attribute.attinhcount
(number of times column is inherited from parent table(s)) for the
seemingly-misbehaving columns.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs