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 <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
