Ok, big bundled up reply here to various people. > From: Greg Copeland <[EMAIL PROTECTED]> > > > 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.... > Hmmm...there might be. Curt raises in interesting point below. Do keep > in mind that I believe he's specifically referring to table inheritance > and not the broad scope of "language wide" inheritance. Yes. > > 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. > From: Oliver Elphick <[EMAIL PROTECTED]> > > 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. 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 column will be unique--and then they aren't.) I consider breaking the relational model this badly a completely unacceptable cost no matter what additional functionality you're wanting to add, and I expect that most other people do, too. > From: Greg Copeland <[EMAIL PROTECTED]> > > 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. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
