Re: TODO: trigger features

Tom Lane wrote:

>Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>
>>I wonder why you are suggesting workarounds for features that other
>>databases provide.
>>
>>
>
>The fact that other databases provide 'em doesn't make them good ideas.
>In particular, writing a trigger that assumes that only the fields
>changed by the original UPDATE syntax have really changed seems like an
>excellent way to shoot yourself in the foot. Why should we go out of
>our way to provide support for error-prone programming techniques?
>
So you want to make a system fool-proof by not providing features?
Working with nested triggers is certainly nothing to be considered for
the newbie.

It's very easy to find these fields, because they can be identified from
old.field <> new.field. My concern is about fields that can *not* be
identified by this comparision. This needs special handling, just as
NULL is handled in a special way (you wouldn't like a suggestion to
handle NULL as zero or empty string, and have an additional bool column
to designate the "empty" state, would you?!?)

Regards,
Andreas