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.
> 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.
> Comments? I'm going to implement and commit this today unless I hear
> loud squawks ...
If we're going to make changes to the inheritance logic, we could
certainly use some more thought than a few hours. If you want to revert
the patch that was installed in 7.0 then ok, but the rest is not
appropriate right now, IMHO.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
