Martin Renters <martin@datafax.com> writes:
> Backend crash with attached script
> The original issue that triggered this was an attempt to implement field
> auditing in 7.0beta3. It worked fine as long as the fields were not NULL.
> I've simplified the code as much as possible to only print values
> rather than writing them into an audit table.
> In particular, in the trigger the values printed for old and new are
> correct if the field being updated is non NULL. If either the old or new
> value for the field is NULL then the values printed in the notice are
> wrong.
I've fixed the immediate coredump exhibited by your script, which is
that the plpgsql RAISE statement was careless about checking for a NULL
value supplied to it. But I suspect that that was not your original
problem but was something you tripped over while investigating it.
Most likely, your real problem is this: at present, a called function
cannot distinguish which of its arguments are NULL --- if any of them
are NULL, then all appear to be (and the function's result is forced
to be NULL, too, which might make one wonder why it's executed at all).
This happens because the function call protocol only provides a single
isNull flag for the entire call operation.
This problem doesn't arise for triggers, since the data is not passed
to them as parameters, but it's a big problem for any functions you
call from the trigger.
Revising the function call protocol is high on our to-do list for 7.1.
regards, tom lane
