On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Tom Dunstan <pg...@tomd.cc> writes: > > On 4 July 2014 00:07, Tom Lane <t...@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". > > regards, tom lane > -- Rushabh Lathia
