RE: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: ALTER TABLE DROP COLUMN
Date
Msg-id 001201bfd4e4$9638cc80$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: ALTER TABLE DROP COLUMN  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
Responses Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Alfred Perlstein
Date:
Subject: Re: Caching number of blocks in relation to avoi lseek.
Next
From: Chris Bitmead
Date:
Subject: Re: ALTER TABLE DROP COLUMN