On thinking about it I can definitely see your point about wanting an
attrid that is common across the hierarchy, regardless of compiled
plans. There would be some merit in splitting up pg_attribute into two
parts. One part is common across all classes in the hierarchy, the other
part is specific to one class. Then the oid of the common part is the
attrid you refer to.
However, I'm not sure this directly affects Tom's proposal. Selects from
hierarchies are implemented in terms of a union of all the classes in
the hierarchy. Wouldn't the compiled plan refer to physical ids? In any
case, if UNION can be made to work, I would think select hierarchies
automatically would work too.
Hiroshi Inoue wrote:
>
> > -----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@tpf.co.jp