Re: "RETURNING PRIMARY KEY" syntax extension
От | Rushabh Lathia |
---|---|
Тема | Re: "RETURNING PRIMARY KEY" syntax extension |
Дата | |
Msg-id | CAGPqQf2BbD1YBmWFo-R-2MVsTdhS3RaYcYcrU8T4gjrH41QJjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: "RETURNING PRIMARY KEY" syntax extension (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "RETURNING PRIMARY KEY" syntax extension
|
Список | pgsql-hackers |
On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It sounds to me like designing this for JDBC's getGeneratedKeys methodI might be mistaken, but as I read the spec for getGeneratedKeys, whether
>> is a mistake. There isn't going to be any way that the driver can support
>> that without having looked at the table's metadata for itself, and if
>> it's going to do that then it doesn't need a crutch that only partially
>> solves the problem anyhow.
> Sure it can - it append RETURNING PRIMARY KEY and hand back a ResultSet
> from whatever was returned. It's CURRENTLY doing that, but it's appending
> RETURNING * and leaving it up to the caller of getGeneratedKeys() to work
> out which columns the caller is interested in.
or not a column is in a primary key has got nothing to do with whether
that column should be returned. It looks to me like what you're supposed
to return is columns with computed default values, eg, serial columns.
(Whether we should define it as being *exactly* columns created by the
SERIAL macro is an interesting question, but for sure those ought to be
included.) Now, the pkey might be a serial column ... but it equally
well might not be; it might not have any default expression at all.
And there certainly could be serial columns that weren't in the pkey.
100% agree with Tom.
The fact that the spec is kinda fuzzy doesn't entitle us to ignore the
plain meaning of the term "generated key".
regards, tom lane
--
Rushabh Lathia
В списке pgsql-hackers по дате отправления: