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