Re: "RETURNING PRIMARY KEY" syntax extension

Andres Freund  writes:
> On 2014-06-11 00:21:58 +0200, Vik Fearing wrote:
>> What?  AFAIK, that only applies to an index.  How can the data itself be
>> partial?

> I don't follow? Gavin above talked about unique keys - which in postgres
> you can create using CREATE UNIQUE INDEX. And if you make those partial
> they can't be used for this purpose.

I have a feeling this conversation is going in the wrong direction.
ISTM that to be useful at all, the set of columns that would be returned
by a clause like this has to be *extremely* predictable; otherwise the
application won't know what to do with the results.  If the app has to
examine the table's metadata to identify what it's getting, what's the
point of the feature at all as opposed to just listing the columns you
want explicitly?  So I doubt that the use-case for anything more
complicated than returning the primary key, full stop, is really there.

I'm not even 100% sold that automatically returning the primary key
is going to save any application logic.  Could somebody point out
*exactly* where an app is going to save effort with this type of
syntax, compared to requesting the columns it wants by name?
Is it going to save enough to justify depending on a syntax that won't
be universal for a long time to come?
		regards, tom lane