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

On Fri, Mar 30, 2001 at 12:10:59PM -0500, Tom Lane wrote:
> ncm(at)zembu(dot)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?
>
> 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.

Treatment of like-named members of multiple base types is not done
consistently in the various O-O languages. It's really a snakepit, and
anything you do automatically will cause terrible problems for somebody.
Nonetheless, for any given circumstances some possible approaches are
clearly better than others.

In C++, as in most O-O languages, the like-named members are kept
distinct. When referred to in the context of a base type, the member
chosen is the "right one". Used in the context of the multiply-derived
type, the compiler reports an ambiguity, and you are obliged to qualify
the name explicitly to identify which among the like-named inherited
members you meant. You can declare which one is "really inherited".
Some other languages presume to choose automatically which one they
think you meant. The real danger is from members inherited from way
back up the trees, which you might not know one are there.

Of course PG is different from any O-O language. I don't know if PG
has an equivalent to the "base-class context". I suppose PG has a long
history of merging like-named members, and that the issue is just of
the details of how the merge happens.

> 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.)

Sounds like a TODO item...

Do all the triggers of the base tables get applied, to be run one after
another?

--
Nathan Myers
ncm(at)zembu(dot)com