Re: Inheritance - Mailing list pgsql-hackers

On Thu, 2002-09-05 at 10:52, Curt Sampson wrote:
> On 5 Sep 2002, Hannu Krosing wrote:
> 
> > What I meant was that it is relatively more costly to update several
> > "physical" tables than updating one .
> 
> Oh, I see. Not that this is that big a deal, I think. Given that
> it doesn't work correctly at the moment, making it work fast is a
> definite second priority, I would think.

But choosing an implementation that _can_be_ made to work fast is not.

> Once it's working right, one can always replace the internals with
> something else that does the same job but is more efficient.

I still think that choosing the right implementation can also help in
making it work right.

> > > I agree that making constraints work in this model is very difficult and
> > > a lot of work.
> >
> > But again this is not _conceptually_ hard, just hard to implement
> > efficiently.
> 
> No, it's conceptually hard. Not all constraints are implemented with
> just a unique index you know. And changing a constraint means you have
> to check all the child tables, etc. etc. It's difficult just to track
> down down all the things you have to try to preserve.

It may be a lot of work, but not _conceptually_ hard. Conceptually you
have to do the same thing as for a single table, but just for all
inherited tables.

> Not to mention,
> there's always the question of what happens to triggers and suchlike
> when handed a tuple with extra columns from what it expects, and having
> it modify the insert into a different table.

IMHO that the trigger should not be aware of underlying implementation -
so it needs not worry about modifying the insert into a different table.

> The beauty of storing all supertable columns in the supertable itself is
> that the behaviour is automatically correct.

But "automatically correct" may not be what you want ;)

What about trigger that generates a cached printname using function
printname(row) that is different for each table - here you definitely do
not want to run the function defined for base table for anything
inherited.

> > What I was actually trying to describe was that the tuple format would
> > be what it is currently, just stored in the same table with parent.
> 
> So what you're saying is that each tuple in the table would have a
> format appropriate for its "subtype," and the table would be full of
> tuples of varying types? At first blush, that seems like a reasonable
> approach, if it can be done.

At least it makes some parts easier ;)

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