On 4 August 2010 14:43, Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> wrote:
>>> 3) You can't set the RETURNING results. You suggested that
>>> RETURNING for DELETE would return the OLD value, but that seems
>>> broken because that's not necessarily what was deleted.
>>
>> Well that's what happens for a table. Alternatively the trigger could
>> modify OLD, and then have RETURNING return that, but that's not what
>> happens in a BEFORE DELETE trigger on a table.
>
> I'm not sure I understand. RETURNING in DELETE on a table fetches the old
> value after it was DELETEd, so it really is what the tuple was before the
> DLETE, not what is seen by the snapshot. In a BEFORE DELETE trigger, the
> row is always locked so it can't change after the trigger is fired.
>
Ah, I think I mis-understood. If I understand what you're saying
correctly, you're worried that the row might have been modified in the
same query, prior to being deleted, and you want RETURNING to return
the updated value, as it was when it was deleted.
So yes, you're right, that really is different from a table. I guess
it would have to be handled by the trigger returning a modified copy
of OLD for RETURNING to use.
Regards,
Dean