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

From Hannu Krosing
Subject Re: OOP real life example (was Re: Why is MySQL more
Date
Msg-id 1029295579.3100.45.camel@rh72.home.ee
Whole thread Raw
In response to Re: OOP real life example (was Re: Why is MySQL more  (Curt Sampson <cjs@cynic.net>)
Responses Re: OOP real life example (was Re: Why is MySQL more  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2002-08-14 at 09:49, Curt Sampson wrote:
> On Wed, 14 Aug 2002, Bruce Momjian wrote:
> 
> > OK, great summary.  Isn't the bottom-line issue the limitation of not
> > being able to create an index that spans tables?
> 
> That would be one way to fix one particular problem. I can think of
> another way to fix it right off-hand. (Put the parent's part of the data
> in the parent table, the child's part in the child table and join.) But
> we haven't completely worked out what effect this has on other parts of
> the system, or what effect we're even looking for.

It would be cleaner in some parts while making things messier in others.

This would make INSERTs and UPDATEs much more complicated, and also
there would be a lot of joins for deeper inheritance hierarchies.

> An an example, at this point some people (including me) feel that
> constraints (*all* constraints) placed on a supertable should always
> work. This means that one should not be able to insert into a subtable
> anything that would break a supertable constraint, and one should not be
> able to add a constraint to a supertable that's violated by a subtable.

Agreed. Most of this would be easy to implement for curent
implementation (but perhaps no more efficient than when done by manually
added rules/triggers) if constraints could contain subqueries.

------------
Hannu





pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] CREATE TEMP TABLE .... ON COMMIT
Next
From: Bruce Momjian
Date:
Subject: Re: journaling in contrib ...