Andreas Pflug <[EMAIL PROTECTED]> writes: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.
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?
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
