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

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