Re: WIP: Triggers on VIEWs

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: WIP: Triggers on VIEWs
Дата
Msg-id AANLkTimnn2v9MMTTMQxvAP77cdwumwgvk7kxmV-cV4vp@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Triggers on VIEWs  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Ответы Re: WIP: Triggers on VIEWs  (Bernd Helmle <mailings@oopsware.de>)
Список pgsql-hackers
On 23 September 2010 00:26, Marko Tiikkaja
<marko.tiikkaja@cs.helsinki.fi> wrote:
> On 2010-09-23 1:16 AM, Bernd Helmle wrote:
>>
>> INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
>>   text  | id
>> --------+----
>>  helmle |  2
>> (1 row)
>>
>> SELECT * FROM vfoo;
>>  text  | id
>> -------+----
>>  bernd |  2
>> (1 row)
>>
>> This is solvable by a properly designed trigger function, but maybe we
>> need
>> to do something about this?
>
> I really don't think we should limit what people are allowed to do in the
> trigger function.
>
> Besides, even if the RETURNING clause returned 'bernd' in the above case, I
> think it would be even *more* surprising.  The trigger function explicitly
> returns NEW which has 'helmle' as the first field.
>

Yes, I agree. To me this is the least surprising behaviour. I think a
more common case would be where the trigger computed a value (such as
the 'last updated' example). The executor doesn't have any kind of a
handle on the row inserted by the trigger, so it has to rely on the
function return value to support RETURNING.

I can confirm the latest Oracle (11g R2 Enterprise Edition) does not
support RETURNING INTO with INSTEAD OF triggers (although it does work
with its auto-updatable views), presumably because it's triggers don't
return values, but I think it would be a shame for us to not support
it.

Regards,
Dean


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Easy way to verify gitignore files?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: snapshot generation broken