Re: Re: Changing the default value of an inherited column - Mailing list pgsql-hackers

ncm@zembu.com (Nathan Myers) writes:
> The O-O principle involved here is Liskov Substitution: if the derived
> table is used in the context of code that thinks it's looking at the
> base table, does anything break?

Good point.  That answers my concern about how to handle typmod: an
application *could* be broken by a change in typmod (eg, suppose it's
allocated a buffer just big enough for a char(N) attribute, using the N
of the parent table).  Therefore we must disallow changes in typmod in
child tables.

Further study of creatinh.c shows that we have inconsistent behavior at
the moment, as it will allow columns of the same name to be inherited
from multiple parents and (silently) combined --- how is that really
different from combining with an explicit specification?


I propose the following behavior:

1. A table can have only one column of a given name.  If the same
column name occurs in multiple parent tables and/or in the explicitly
specified column list, these column specifications are combined to
produce a single column specification.  A NOTICE will be emitted to
warn the user that this has happened.  The ordinal position of the
resulting column is determined by its first appearance.

2. An error will be reported if columns to be combined do not all have
the same datatype and typmod value.

3. The new column will have a default value if any of the combined
column specifications have one.  The last-specified default (the one
in the explicitly given column list, or the rightmost parent table
that gives a default) will be used.

4. All relevant constraints from all the column specifications will
be applied.  In particular, if any of the specifications includes NOT
NULL, the resulting column will be NOT NULL.  (But the current
implementation does not support inheritance of UNIQUE or PRIMARY KEY
constraints, and I do not have time to add that now.)

This behavior differs from prior versions as follows:

1. We return to the pre-7.0 behavior of allowing an explicit
specification of a column name that is also inherited (7.0 rejects this,
thereby preventing the default from being changed in the child).
However, we will now issue a warning NOTICE, to answer the concern that
prompted this change of behavior.

2. We will now enforce uniformity of typmod as well as type OID when
combining columns.

3. In both 7.0 and prior versions, if a column appeared in multiple
parents but not in the explicit column list, the first parent's default
value (if any) and NOT NULL state would be used, ignoring those of later
parents.  Failing to "or" together the NOT NULL flags is clearly wrong,
and I believe it's inconsistent to use an earlier rather than later
parent's default value when we want an explicitly-specified default to
win out over all of them.  The explicit column specifications are
treated as coming after the last parent for other purposes, so we should
define the default to use as the last one reading left-to-right.

Comments?  I'm going to implement and commit this today unless I hear
loud squawks ...
        regards, tom lane