Re: OOP real life example (was Re: Why is MySQL more - Mailing list pgsql-hackers

On 13 Aug 2002, Greg Copeland wrote:

> On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
> > I will revise my opinion the instant someone shows me something that I
> > can't do relationally, or is easy to implement with inheritance, and
> > difficult with relational methods. Now you know what you need to do, and
> > if you have no example, we can drop the whole thing. But I am honestly
> > interested to see just what it is that makes table inheritance so great.
>
> I think here-in is the first problem.  You seem to insist that the world
> can only allow for one or the other and that the two approaches are
> mutually exclusive.

No, I don't.
   1. If it changes the rules, as it were, that is breaks other   parts of the system, it should go. This is the
currentstate   of the postgres implementation. I'm guessing it's not the state   of the desired implementation, once we
figureout what that is.
 
   2. If it's just syntactic sugar, that's livable, so long as   it's quite obvious what it's syntatic sugar for. (In
thecurrent   case, it's not.) It's even good if it saves a lot of effort.
 
   3. If it actually allows you to do something you cannot otherwise   do, or allows you to do something very difficult
withmuch   greater ease, it's a good thing and it should stay.
 

> > Well, assuming we are mapping inheritance back into relational stuff
> > behind the scenes (which it appears to me we are doing now), we can just
> > map back to the relation method I demonstrated earlier of doing what
> > someone wanted to do with table inheritance (child tables contain only
> > foreign key and child-specific data; parent table contains primary key
> > and all parent data) and that will fix the implementation problem.
>
> This is what I imagined the preferred solution would be, however, I'm
> also assuming it would be the more complex to implement *properly*.

I don't think so. Both systems are currently, AFICT, pretty simple
mappings onto the relational system. Once we get the exact details of
table inheritance behaviour hammered out, I will gladly provide the
mapping it's possible to create it.

> >     Date, Darwen, _Foundation for Future Database Systems, The
> >     Third Manefesto (Second Edition)_. Appendex E.
>
> Is this a book or a paper.  I have a paper that I've been reading
> (ack...very, very dry) by these guys of the same name.

It's a book. Apparently the paper is, in comparison, much more lively.
:-) But I find the book good in that, at the very least, it shows the
level to which you have to go to come up with a theoretically solid
basis for something you want to implement.

> So the SQL standard does address table inheritance?

Yes.

> Not that this means I feel that they've done the right thing...but
> what did the specification have to say on the subject? Any online
> references?

I don't have a copy of the spec handy, and have not had time to go and
dig one up. All I got from it was out of the two book references I gave.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC