Re: ALTER TABLE DROP COLUMN

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE DROP COLUMN
Дата
Msg-id 10290.960868446@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: ALTER TABLE DROP COLUMN  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Ответы RE: ALTER TABLE DROP COLUMN  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> create table t1 (i1 int4);
> create table t2 (i2 int4) inherits t1;
> create table t3 (i3 int4) inherits t2;
> alter table t1 add column i4 int4;

> For each table,the list of (column, logical number, physical number)
> would be as follows.

> t1   (i1, 1, 1) (i4, 2, 2)
> t2   (i1, 1, 1) (i4, 2, 3) (i2, 3, 2)
> t3   (i1, 1, 1) (i4, 2, 4) (i2, 3, 2) (i3, 4, 3)

> At this point the compilation of 'select * from t1(*?)' would mean
>     select (physical #1),(physical #2) from t1  +
>     select (physical #1),(physical #3) from t2  +
>     select (physical #1),(physical #4) from t3 

> Note that physical # aren't common for column i4.

That's no different from the current situation: the planner already must
(and does) adjust column numbers for each derived table while expanding
an inherited query.  It's kind of a pain but hardly an insurmountable
problem.

Currently the matching is done by column name.  We could possibly match
on logical column position instead --- not sure if that's better or
worse.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: Re: ALTER TABLE DROP COLUMN
Следующее
От: JanWieck@t-online.de (Jan Wieck)
Дата:
Сообщение: Re: Patch for 'Not to stuff everything as files in a single directory, hash dirs''