Re: "RETURNING PRIMARY KEY" syntax extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
Cc: Ian Barwick <ian(at)2ndquadrant(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "RETURNING PRIMARY KEY" syntax extension
Date: 2014-07-03 14:37:38
Message-ID: 21589.1404398258@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> writes:
> On Thu, Jul 3, 2014 at 6:56 AM, Ian Barwick <ian(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2014-07-03 15:51:36 Re: docs: additional subsection for page-level locks in explicit-locking section
Previous Message Tom Lane 2014-07-03 14:16:01 Re: Setting PG-version without recompiling