Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> At any rate, I think we might want to apply Tom's patch for this
>> while 9.3 is still early in development, to see what else might
>> shake out from it while there is still plenty of time to fix any
>> issues. It's now looking good from my perspective.
>
> I just re-read the thread to refresh my memory. It seems that we
> pretty much had consensus on throwing an error if any operation
> fired by a BEFORE UPDATE/DELETE trigger changes the target row,
> unless the trigger returns NULL to skip the update/delete. It is
> not clear to me however whether we had consensus about what to do
> with SELECT FOR UPDATE locking cases. The last patch posted in
> the thread was here:
>
> http://archives.postgresql.org/pgsql-hackers/2012-01/msg01241.php
>
> That message includes an example of the FOR UPDATE problem case
> and says that fixing it would require significantly more work. Do
> we want to worry about tackling that now, or shall we be satisfied
> with fixing the trigger cases?
As you said in the referenced message, the FOR UPDATE issue seems
orthogonal and should probably be addressed separately.
> Also, it doesn't appear that we ever got around to preparing
> documentation updates, but I think we definitely need some if
> we're going to start throwing errors for things that used to be
> allowed. Since Kevin has the most field experience with this
> problem, I'd like to nominate him to write some docs ...
OK, will do. The "redo the DELETE and RETURN NULL" workaround is
not at all obvious; we should definitely include an example of that.
-Kevin