Changing the default value of an inherited column
От | Tom Lane |
---|---|
Тема | Changing the default value of an inherited column |
Дата | |
Msg-id | 18936.985804230@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Changing the default value of an inherited column
Re: Changing the default value of an inherited column |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: