Re: "RETURNING PRIMARY KEY" syntax extension

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "RETURNING PRIMARY KEY" syntax extension
Date: 2014-06-26 20:44:44
Message-ID: 53AC863C.5080908@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27/06/14 00:12, Rushabh Lathia wrote:
> 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.
>
>
[...]

I agree 100%.

I note that DELETE & INSERT have a RETURNING clause. So the semantics
and syntax should be the same, as much as is practicable.

Cheers,
Gavin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-06-26 21:01:10 Spinlocks and compiler/memory barriers
Previous Message Petr Jelinek 2014-06-26 20:43:33 Re: review: Built-in binning functions