On 5 Sep 2002, Hannu Krosing wrote: > > 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.
I would say it definitely is. A correctly working implementation can be replaced. An incorrectly working implementation destroys data integrety. Which is more important for PostgreSQL? Speed or maintaining data integrity? > > 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. I agree. > > 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. Right. But that will be "automatically correct" when you store all base data in the base table. It's when you start storing those data in other tables that the trigger can get confused. Or are you saying that when I insert a row into "just" a child table, the trigger shouldn't be invoked on the "parent table" portion of that insert? If so, I'd strongly disagree. If that trigger is acting as an integrety constraint on the base table, you might destroy the table's integrity. 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 6: Have you searched our list archives? http://archives.postgresql.org
