Skip site navigation (1) Skip section navigation (2)

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

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Changing the default value of an inherited column
Date: 2001-03-30 21:30:35
Message-ID: 20010330133035.F3797@store.zembu.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Nathan MyersDate: 2001-03-30 21:40:25
Subject: Re: Re: Changing the default value of an inherited column
Previous:From: Tom LaneDate: 2001-03-30 21:15:36
Subject: Re: Re: Changing the default value of an inherited column

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group