Re: Re: Changing the default value of an inherited column

Peter Eisentraut <peter_e@gmx.net> writes:
>> 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 is definitely a violation of that Liskov Substitution.  If a context
> expects a certain table and gets a more restricted table, it will
> certainly notice.

Au contraire --- I'd say that if the child table fails to adhere to the
constraints set for the parent table, *that* is a violation of
inheritance.  In particular, a table containing NULLs that is a child of
a table in which the same column is marked NOT NULL is likely to blow up
an application that is not expecting to get any nulls back.

In any case, we have already been inheriting general constraints from
parent tables.  Relaxing that would be a change of behavior.  The
failure to inherit NOT NULL constraints some of the time (in some cases
they were inherited, in some cases not) cannot be construed as anything
but a bug.

> If we're going to make changes to the inheritance logic, we could
> certainly use some more thought than a few hours.

The primary issue here is to revert the 7.0 behavior to what it had been
for many years before that, and secondarily to make NOT NULL inheritance
behave consistently with itself and with other constraints.  It doesn't
take hours of thought to justify either.

I will agree that left-to-right vs. right-to-left precedence of
inherited default values is pretty much a random choice, but it's
doubtful that anyone is really depending on that.  The existing behavior
was not self-consistent anyway, since it was actually not "the first
specified default" but "the default or lack of same attached to the
first parent containing such a field".  For example, if we do not change
this behavior then
create table p1 (f1 int);create table p2 (f1 int default 1) inherits(p1);

results in p2.f1 having a default, while
create table p1 (f1 int);create table p2 (f1 int default 1, f2 int);create table p3 (f3 int) inherits(p1, p2);

results in p3.f1 not having a default.  I don't think that can be argued
to be anything but a bug either (consider what happens if p2 also says
NOT NULL for f1).
        regards, tom lane