RE: ALTER TABLE DROP COLUMN

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

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp