On Mon, 2002-08-12 at 20:34, Curt Sampson wrote: > 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....
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 <[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. 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 <[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. 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
signature.asc
Description: This is a digitally signed message part
