Tom Dunstan <pgsql@tomd.cc> writes: > On 4 July 2014 00:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It sounds to me like designing this for JDBC's getGeneratedKeys method >> 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.
I might be mistaken, but as I read the spec for getGeneratedKeys, whether 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".
