2012/9/20 Tom Lane <t...@sss.pgh.pa.us>: > "Kevin Grittner" <kgri...@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 had same idea when I worked on SQL/PSM - but there is significant difference in performance (probably less in real tasks) 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. when fields are fix length, then field's update is significantly faster then when RECORD is used > >> - 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 > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers