Re: Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)

From: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
To: Stephan Szabo <sszabo(at)kick(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
Date: 2000-07-20 00:31:37
Message-ID: 39764869.B9FA73C8@nimrod.itg.telecom.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2000-07-20 00:50:06 Re: Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
Previous Message Mikheev, Vadim 2000-07-20 00:22:36 RE: unique constraint - bug?

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-07-20 00:41:55 RE: btree split logic is fragile in the presence of lar ge index items
Previous Message Tom Lane 2000-07-20 00:21:04 Re: btree split logic is fragile in the presence of lar ge index items