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

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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Changing the default value of an inherited column
Date: 2001-03-30 21:05:53
Message-ID: Pine.LNX.4.30.0103302259010.1063-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
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      peter_e(at)gmx(dot)net       http://yi.org/peter-e/


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-30 21:15:36
Subject: Re: Re: Changing the default value of an inherited column
Previous:From: Mike MascariDate: 2001-03-30 20:50:02
Subject: RE: 7.1 pg_dump fails for user-defined types (release stopper?)

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