Re: "RETURNING PRIMARY KEY" syntax extension - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "RETURNING PRIMARY KEY" syntax extension
Date
Msg-id 21589.1404398258@sss.pgh.pa.us
Whole thread Raw
In response to Re: "RETURNING PRIMARY KEY" syntax extension  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Responses Re: "RETURNING PRIMARY KEY" syntax extension  (Greg Stark <stark@mit.edu>)
Re: "RETURNING PRIMARY KEY" syntax extension  (Tom Dunstan <pgsql@tomd.cc>)
List pgsql-hackers
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick <ian@2ndquadrant.com> wrote:
>> A better solution would be to have an optional "IF EXISTS" clause:
>> RETURNING PRIMARY KEY [ IF EXISTS ]

> Hmm liked the idea about adding [ IF EXISTS ]. Looking at the grammar so
> far we
> having [ IF EXISTS ] option only for DDL commands (mainly DROP) not sure
> whether
> its ok to use such syntax for DML commands.

> Others please share your thoughts/comments.

TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy
in that the application would have little idea what it was getting back.
IF EXISTS would make it so spongy as to be useless, IMO.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Setting PG-version without recompiling
Next
From: Kevin Grittner
Date:
Subject: Re: docs: additional subsection for page-level locks in explicit-locking section