Richard Huxton wrote:
>> I just noticed this (odd?) behaviour, and it kind of
>> scares me.
>
>> Isn't this a little fragile? Is there something I
>> could do to avoid this situation? Should trigger
>> functions be extremely simple as to guarantee that
>> an error would never happen?
>
> There's nothing else it can do, really. Far better that the whole update
> fails than you get an inconsistent database.
>
> Imagine you have a banking system, and every time you add a row to the
> transaction-history, you update the "current_balance" table. Which would
> you prefer, both updates fail, or the two get out of sync?
Yes, you are absolutely correct.
I guess the concern came up as result of a particular
situation, in which failing to properly process the
trigger function is not that crucial (I wanted to
update some additional information that is "optional",
and that can be reconstructed easily after discovering
that the trigger function had been failing). But in
our case, failing to complete the update is rather
critical (things can be reconstructed but under certain
conditions only, and only by temporarily shutting down
the system for a few minutes).
So, I was thinking that there may be a way for the user
to instruct PG to ignore the fact that the trigger
function failed -- that way, we would overcome the
difficulties that you mention in improving dependency
checking when functions are involved -- PG wouldn't have
to determine it: the user would tell it.
> So - how do you deal with this? Well, you test.
Fair enough.
Thanks!
Carlos
--