From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Curt Sampson <cjs(at)cynic(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Gulutzan <71022(dot)733(at)compuserve(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inheritance |
Date: | 2002-09-05 10:23:54 |
Message-ID: | 1031221434.17320.151.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2002-09-05 10:29:43 | Re: Inheritance |
Previous Message | Vince Vielhaber | 2002-09-05 10:23:09 | Re: Map of developers |