Re: "RETURNING PRIMARY KEY" syntax extension

On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Tom Dunstan <pgsql(at)tomd(dot)cc> writes:
> > On 4 July 2014 00:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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