RE: ALTER TABLE DROP COLUMN

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: ALTER TABLE DROP COLUMN
Дата
Msg-id 001201bfd4e4$9638cc80$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на Re: ALTER TABLE DROP COLUMN  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
Ответы Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> -----Original Message-----
> From: Chris Bitmead
> 
> Hiroshi Inoue wrote:
> 
> > I don't understand inheritance well. In the near future wouldn't the
> > implementation require e.g. attid which is common to all children
> > of a parent and is never changed ? If so,we would need the third
> > attid field which is irrevalent to physical/logical position. If not,
> > physical column number would be sufficient .
> 
> We only need something like a unique attid of course if we support
> column renaming in child tables. Otherwise the attname is sufficient to
> match up child-parent columns.
>

There are some objects which keep plans etc as compiled
state.

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 meanselect (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.
I've wanted to confirm that above compilation would be OK for 
the (near) future enhancement of inheritance functionality.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



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

Предыдущее
От: Alfred Perlstein
Дата:
Сообщение: Re: Caching number of blocks in relation to avoi lseek.
Следующее
От: Chris Bitmead
Дата:
Сообщение: Re: ALTER TABLE DROP COLUMN