Re: ADD/DROP INHERITS
От | Tom Lane |
---|---|
Тема | Re: ADD/DROP INHERITS |
Дата | |
Msg-id | 1115.1149799629@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ADD/DROP INHERITS (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: ADD/DROP INHERITS
|
Список | pgsql-hackers |
Greg Stark <gsstark@mit.edu> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> So? They'll get re-merged with the parent column during CREATE TABLE >> anyway. > But merged columns that are defined locally still appear in the position they > were defined locally. Not with the other inherited columns. Really? regression=# create table p (p1 int, p2 int, p3 int); CREATE TABLE regression=# create table c (c1 int, c2 int) inherits (p); CREATE TABLE regression=# create table gc (gc1 int, p2 int, c1 int, gc2 int) inherits (c); NOTICE: merging column "p2" with inherited definition NOTICE: merging column "c1" with inherited definition CREATE TABLE regression=# \d gc Table "public.gc"Column | Type | Modifiers --------+---------+-----------p1 | integer |p2 | integer |p3 | integer |c1 | integer |c2 | integer |gc1 | integer |gc2 | integer | Inherits: c regression=# > Basically I think if you're doing multiple inheritance and start using > add/drop inherits your column order is going to turn into chop suey quickly. Very possibly, but that doesn't mean that we shouldn't take any concern for avoiding unnecessary changes. regards, tom lane
В списке pgsql-hackers по дате отправления: