On 23 September 2010 00:26, Marko Tiikkaja
<marko.tiikk...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
