2012/9/20 Tom Lane :
> Pavel Stehule writes:
>> 2012/9/20 Tom Lane :
>>> 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.
>
>>
Pavel Stehule writes:
> 2012/9/20 Tom Lane :
>> 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, t
2012/9/20 Tom Lane :
> "Kevin Grittner" 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
"Kevin Grittner" 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.
Related to bug #6123, Wisconsin Courts are now using triggers with
the workaround to be safe with the patch put forward by Tom, even
though they are still running with the earlier patch proposal by me
(which tolerates an UPDATE or DELETE of a row being deleted). The
general structure of the BEFORE
