Re: GSOC13 proposal - extend RETURNING syntax

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Karol Trzcionka <karlikt(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GSOC13 proposal - extend RETURNING syntax
Date: 2013-05-02 15:58:57
Message-ID: 51828D41.9060307@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-05-02 16:23:19 Re: GSOC13 proposal - extend RETURNING syntax
Previous Message Karol Trzcionka 2013-05-02 15:32:39 Re: GSOC13 proposal - extend RETURNING syntax