Re: [HACKERS] Inheritance, referential integrity and other constraints

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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden