I just had a discussion with a user who doesn't want to update from
6.4.something to 7.0.* because 7.0 broke a feature he likes, namely
the ability to change the default value of a column inherited from
a parent table. It seems that in pre-7.0 Postgres, this works:
create table one(id int default 1, descr text);
create table two(id int default 2, tag text) inherits (one);
with the net effect that table "two" has just one "id" column with
default value 2.
I can recall a number of requests from users to be able to change
the default value when inheriting a column, but I had not realized
that it was actually possible to do this in older Postgres releases.
After digging into the CVS logs and mail archives, I find that Peter E.
changed the behavior in January 2000, apparently without realizing that
he was disabling a feature that some considered useful. Here's his
comment in pghackers, 26 Jan 2000 19:35:14 +0100 (CET):
> ... I just looked into item 'Disallow inherited columns
> with the same name as new columns' and it seems that someone actually made
> provisions for this to be allowed, meaning that
> create table test1 (x int);
> create table test2 (x int) inherits (test1);
> would result in test2 looking exactly like test1. No one knows what the
> motivation was. (I removed it anyway.)
Given that Peter was responding to a TODO item, evidently someone had
complained about the lack of any complaint for this construction, but
I wonder whether the someone really understood all the implications.
Allowing this construction allows one to change the default, or add
(but not remove) column constraints, and in general it seems kinda
useful.
The question of the day: should we put this back the way it was?
If so, should we try to squeeze it into 7.1, or wait another release
cycle? (I can see about equally good arguments for considering this
a feature addition or a bug fix...) Should there be a NOTICE about
the duplicated column name, or is the old silent treatment okay?
regards, tom lane
