Stephan Szabo wrote:
> > Storing oids of attributes sounds like a problem in this context because
> > it may make it hard to relate these to sub-classes. I do really think
> > that the system catalogs should be re-arranged so that attributes have
> > two parts - the parts that are specific to that class, and the parts
> > that also apply to sub-classes. For example the type and the length
> > should probably apply to sub-classes. The attnum and the name should
> > probably be individual to each class in the hierarchy. (The name should
> > be individual to support subclass renaming to avoid naming conflicts,
> > like in the draft SQL3 and Eiffel). If it is in two parts then using the
> > oid of the common part would make it easy for your purposes.
> How would one refer to an attribute whose name has changed in a
> subclass if you're doing a select on the superclass (or do you even
> need to do anything - does it figure it out automagically?)
If you had..
create table a (aa text);
create table b under a rename aa to bb ( );
insert into a(aa) values('aaa');
insert into b(bb) values('bbb');
select * from a;
aa
---
aaa
bbb
The system knows that a.aa is the same as b.bb. The same attribute
logically, just referred to by different names depending on the context.
Eiffel handles it the same way if I remember right.
