From: | Ian Barwick <ian(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Jochem van Dieten <jochemd(at)gmail(dot)com> |
Subject: | Re: "RETURNING PRIMARY KEY" syntax extension |
Date: | 2014-06-12 10:25:01 |
Message-ID: | 53997FFD.3040304@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/06/12 18:46, Jochem van Dieten wrote:
> On Wed, Jun 11, 2014 at 2:39 AM, Tom Lane wrote:
>
> I'm not even 100% sold that automatically returning the primary key
> is going to save any application logic. Could somebody point out
> *exactly* where an app is going to save effort with this type of
> syntax, compared to requesting the columns it wants by name?
>
>
> I haven't checked the code, but I am hoping it will help with the problem
> where a RETURNING * is added to a statement that is not an insert or update
> by the JDBC driver. That has been reported on the JDBC list at least twice,
> and the proposed workaround is neither very elegant nor very robust:
> https://groups.google.com/forum/#!msg/pgsql.interfaces.jdbc/7WY60JX3qyo/-v1fqDqLQKwJ
Unfortunately that seems to be a JDBC-specific issue, which is outside
of the scope of this particular patch (which proposes additional server-side
syntax intended to make RETURNING * operations more efficient for
certain use cases, but which is in itself not a JDBC change).
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-12 11:32:32 | Re: Few observations in replication slots related code |
Previous Message | Naoya Anzai | 2014-06-12 10:09:41 | Re: "cancelling statement due to user request error" occurs but the transaction has committed. |