"Kevin Grittner" <kgrittn@mail.com> writes:
> ... This did not work for cases where the AFTER DELETE trigger performed
> an action which was not idempotent because, while return_value was
> NULL enough to enter that last IF clause, it was not NULL enough to
> prevent the DELETE attempt and fire subsequent triggers. The
> assignment of NULL to a variable with a record type doesn't assign a
> "simple" NULL, but a record with NULL in each element.
I believe that this is forced by plpgsql's implementation. IIRC, a
declared variable of a named composite type (not RECORD) is implemented
as a "row" structure, meaning it actually consists of a separate plpgsql
variable for each column. So there's no physical way for it to represent
a "simple NULL" composite value.
I've suggested in the past that we might want to go over to treating
such variables more like RECORD, ie the representation is always a
HeapTuple. I'm not sure what the performance tradeoffs would be ---
some things would get faster and others slower, probably, since field
access would be more work but conversion to/from HeapTuple would get far
cheaper.
> - If we keep this behavior, should the triggering operation be
> suppressed when (NOT return_value IS NOT NULL) instead of when
> (return_value IS NOT DISTINCT FROM NULL)?
Can't do that, because it would break the perfectly-legitimate case
where the trigger is trying to process a row of all nulls.
regards, tom lane
