| 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: | Whole Thread | Raw Message | 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. |