Re: Proposal / proof of concept: Triggers on VIEWs

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal / proof of concept: Triggers on VIEWs
Date: 2010-08-04 14:03:21
Message-ID: AANLkTi=yOV=u__2uNCpPUkxXNjGjG+cQbDeD7HyQ3sof@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4 August 2010 14:43, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2010-08-04 14:08:49 Re: Proposal / proof of concept: Triggers on VIEWs
Previous Message Andrew Dunstan 2010-08-04 13:50:48 Re: documentation for committing with git