Re: GSOC13 proposal - extend RETURNING syntax

From: Karol Trzcionka <karlikt(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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:32:39
Message-ID: 51828717.7030500@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. regards,
> tom lane
I'm not sure about it. If it is not reserved keyword how can user get
old value from table named "old". The new value is not a problem
(doesn't conflict) but 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).
Regards,
Karol Trzcionka

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2013-05-02 15:58:57 Re: GSOC13 proposal - extend RETURNING syntax
Previous Message Tom Lane 2013-05-02 15:17:33 Re: GSOC13 proposal - extend RETURNING syntax