"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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 5 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 20, '12 at 9:05p
activeSep 21, '12 at 4:21a
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase