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

On Mon, 2002-08-12 at 20:34, Curt Sampson wrote:
> Ok, big bundled up reply here to various people.
>
> > From: Greg Copeland <greg@CopelandConsulting.Net>
> >
> > > What makes things more confusing is poor understanding of a feature, not
> > > the feature itself.
> >
> > Agreed.  Just because a feature may not be well understood by the masses
> > doesn't mean the feature is worthless.
>
> Yeah, but if it's not understood by fairly smart people familiar
> with both relational theory and OO programming? If the feature is
> confusing because it appears to be something it's not, that's a
> feature problem, not a problem with the people trying to understand
> it. Maybe all that's necessary to fix it is a terminology change,
> but even so....

You're constantly confusing Postgres' implementation with a "desired"
implementation.  Below, I think, is the effort to figure out exactly
what a "desired implementation" really is.

If a feature is partially implemented, of course it's going to be
confusing to use.

Let's please stop beating this horse Curt.  At this point, I think the
horse is floating upside down in a pond somewhere...yep...and the
buzzards are coming.

Please.  Beating people with a stick isn't suddenly going to make
everyone share your view point.

> > > All _simple_ inheritance problems are easily solved by simple relational
> > > solutions. The general problem of much more typing and debugging, less
> > > clues for optimiser etc. are not solved by _simple_ relational
> > > solutions.
> >
> > I agree with Hannu here.  Curt's comment seems like lip service.
>
> Well, as I said: examples please. Quite frankly, between the lack
> of a clear model of table inheritance (Hannu seems to have one,
> but this needs to be written up in unambiguous form and put into
> the postgres manual) and the bugs in the postgres implementation
> of table inheritance, I've found the relational model much easier
> to use for solving problems.

If you're so keen on examples, please provide one that justifies such a
boastful statement.  Hannu has done a pretty fair job of beating ya back
every time.  Personally, in this case, I don't really need examples are
it's pretty obvious a braggart statement full of bias.  So second
thought, perhaps we can let this one alone.

I do agree that it looks like Hannu is doing a fairly good job of
providing some constructive direction here.  Hannu, please keep up the
good work.  ;)

>
> > From: Oliver Elphick <olly@lfix.co.uk>
> >
> > On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
> > > How exactly would you create an abstract base class for table type?
> >
> > CREATE TABLE abstract_base (
> >    cols ...,
> >    CONSTRAINT "No data allowed in table abstract_base!" CHECK (1 = 0)
> > )
> >
> > This assumes that the constraint is not inherited or can be removed in
> > child tables.
>
> Are we then assuming that tuples in the child tables do not appear
> in the base table? That's more or less what I'd assumed when I
> originally heard about table inheritance (after all, instantiating
> a child object does not automatically instantiate a separate copy
> of the parent object), but the SQL standard, postgres, and I believe other
> systems make the exact opposite assumption.

That's actually my exact assumption...that is, that tuples in the parent
did not exist in the child.  Is that not true?  Can you point me to any
references?

>
> If the child table tuples do appear in the parent, you've now got
> a situation analogous to the current postgres situation where a
> constraint on the parent table is an outright lie. (I'm thinking
> of the UNIQUE constraint which guarantees that all values in a
[snip]

I knew that there are *implementation* issues with postgres that causes
problems with constraints, etc...I didn't realize that was the reason.

>
> > From: Greg Copeland <greg@CopelandConsulting.Net>
> >
> > That, in it self, I find rather interesting.  Is there any papers or
> > books which offers explanation of how constraints should handled for
> > table inheritance?
>
> Here again, I'd love to hear about some references, too. I see a
> lot of people saying they like table inheritance; I don't see anyone
> (except maybe Hannu) who seems to have a clear idea of how it should
> work.

Well, you seem to be making references to "...SQL standard, postgres,
and I believe other systems...".  I was counting on you or someone else
to point us to existing references.  I'm fairly sure we can manage to
wade through it to walk a sane and fruitful path...it would just be a
less bumpier road if we all spoke the same OO'ish dialect and shared a
common knowledge base that we can all agree on for starters.  So, you
got anything to share here???  ;)


Greg