Re: GSOC13 proposal - extend RETURNING syntax - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: GSOC13 proposal - extend RETURNING syntax
Date
Msg-id 51828D41.9060307@joh.to
Whole thread Raw
In response to Re: GSOC13 proposal - extend RETURNING syntax  (Karol Trzcionka <karlikt@gmail.com>)
Responses Re: GSOC13 proposal - extend RETURNING syntax  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2013-05-02 17:32, Karol Trzcionka wrote:
> W dniu 02.05.2013 17:17, Tom Lane pisze:
>> It should in any case be possible to do this without converting them
>> to reserved words; rather the implementation could be that those table
>> aliases are made available when parsing the UPDATE RETURNING
>> expressions. (This is, in fact, the way that rules use these names
>> now.) Probably it should work something like "add these aliases if
>> they don't already exist in the query", so as to avoid breaking
>> existing applications. I don't really see a lot of value in hacking
>> the behavior of either INSERT RETURNING or DELETE RETURNING.
>
> what should happened in statement:
> UPDATE old SET foo=foo+1 RETURNING old.foo;
> If it returns old value, it'll break capability. If it returns new value
> (as now), there is no possibility to get old value (and user cries
> because of broken feature).

In Tom's proposal that would give you the "new" value.

Personally I would maybe prefer reserving NEW/OLD, but if we go through 
with Tom's idea, this should work:

UPDATE old myold SET foo=foo+1 RETURNING myold.foo, old.foo;


What I'm more interested in is: how can we make this feature work in 
PL/PgSQL where OLD means something different?


Regards,
Marko Tiikkaja



pgsql-hackers by date:

Previous
From: Karol Trzcionka
Date:
Subject: Re: GSOC13 proposal - extend RETURNING syntax
Next
From: Tom Lane
Date:
Subject: Re: GSOC13 proposal - extend RETURNING syntax