On Fri, Mar 30, 2001 at 11:05:53PM +0200, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > 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.
>
> This seems pretty random. It would be more reasonable if multiple
> (default) inheritance weren't allowed unless you explicitly specify a new
> default for the new column, but we don't have a syntax for this.
I agree, but I thought the original issue was that PG _does_ now have
syntax for it. Any conflict in default values should result in either
a failure, or "no default". Choosing a default randomly, or according
to an arbitrary and complicated rule (same thing), is a source of bugs.
> > 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.
Not so. The rule is that the base-table code only has to understand
the derived table. The derived table need not be able to represent
all values possible in the base table.
Nathan Myers
ncm@zembu.com