Re: "RETURNING PRIMARY KEY" syntax extension - Mailing list pgsql-hackers

From Rushabh Lathia
Subject Re: "RETURNING PRIMARY KEY" syntax extension
Date
Msg-id CAGPqQf06k2yfr94vWUaUsEdXHDyDP3bXgbaJ9mbo22YtKwvUOw@mail.gmail.com
Whole thread Raw
In response to Re: "RETURNING PRIMARY KEY" syntax extension  (Ian Barwick <ian@2ndquadrant.com>)
Responses Re: "RETURNING PRIMARY KEY" syntax extension  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-hackers
Thanks for sharing latest patch.

For me this syntax is limiting the current returning clause implementation.
Because its not allowing the returning PRIMARY KEYS with other columns, and
if user or application require that they need to do RETURNING *. Following
syntax not working, which i think is very useful in term if someone want to use
returning clause with PRIMARY KEY as well as some other table columns.

INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning primary key, dname;

I think allowing other columns with PRIMARY KEY would be more useful syntax.
Even in later versions if we want to extend this syntax to return UNIQUE KEY,
SEQUENCE VALUES, etc.. comma separation syntax will be more handy.

Others please share your inputs/thoughts.



On Thu, Jun 26, 2014 at 8:11 AM, Ian Barwick <ian@2ndquadrant.com> wrote:
On 25/06/14 16:04, Ian Barwick wrote:
Hi

On 14/06/25 15:13, Rushabh Lathia wrote:
Hello All,

I assigned my self as reviewer of the patch. I gone through the
mail chain discussion and in that question has been raised about
the feature and its implementation, so would like to know what is
the current status of this project/patch.

Regards,

I'll be submitting a revised version of this patch very shortly.

Revised version of the patch attached, which implements the expansion
of "primary key" in the rewrite phase per Tom Lane's suggestion upthread [*]

[*] http://www.postgresql.org/message-id/28583.1402325169@sss.pgh.pa.us



Regards

Ian Barwick

--
 Ian Barwick                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services



--
Rushabh Lathia

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: bad estimation together with large work_mem generates terrible slow hash joins
Next
From: Merlin Moncure
Date:
Subject: Re: better atomics - v0.5