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.
Once it's working right, one can always replace the internals with
something else that does the same job but is more efficient.
> > 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. 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.
The beauty of storing all supertable columns in the supertable itself is
that the behaviour is automatically correct.
> 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.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
