On 2000-01-26, Oliver Elphick mentioned:
> >considered right. Also I just looked into item 'Disallow inherited columns
> >with the same name as new columns' and it seems that someone actually made
> >provisions for this to be allowed, meaning that
> >create table test1 (x int);
> >create table test2 (x int) inherits (test1);
> >would result in test2 looking exactly like test1. No one knows what the
> >motivation was. (I removed it anyway.)
>
> That's a relief! Unless you have actually removed the ability to do
> repeated inheritance?
Ugh, I just realized that of course you _have_ to allow duplicate column
names, e.g. in a scheme like b a < > d c
the columns of "a" would arrive duplicated at "d" and the above logic
would merge them. I haven't finished that fix yet, so I better scrap it
now. Seem like this TODO item was really a non-starter.
> Final note: I have just realised that most of what I am using inheritance
> for could be done with views and unions, provided that we can REFERENCE a
> view (which I haven't tested). One really radical option would be to strip
> out inheritance altogether!
Sure, I could live with that. It's not like it ever worked (in its
entirety). And any
table a (a1, a2, a3)
table b (b1, b2) inherits (a)
can also be implemented as
table a (a_id, a1, a2, a3)
table b_bare (b_id, b1, b2)
create view b as select a1, a2, a3, b1, b2 from outer join a, b on a_id = b_id
{or whatever that syntax was}
plus an insert rule or two.
It would make the rest of the code soooo much easier. (Sarcasm intended,
but a glimpse of truth as well.)
+++
Slashdot: "Self-proclaimed most advanced open-source database drops
object-oriented facilities to simplify code base"
AC reply: "Now when's KDE moving to C?"
+++
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden