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 <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
