From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: updatable cursors and ORDER BY |
Date: | 2018-05-10 16:48:42 |
Message-ID: | 8dc63ba7-dc56-fc7c-fc16-4fae03e3bfe6@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On 5/9/18 22:57, Tom Lane wrote:
> I think you misread that note: it says nothing about what is allowed
> in DECLARE CURSOR per se. It is talking about whether you can apply
> UPDATE/DELETE WHERE CURRENT OF to that cursor. Moreover, what it says
> is that if you use FOR UPDATE then such an UPDATE/DELETE *will* work,
> whereas without it we don't guarantee that.
I think that last part isn't actually written down anywhere. (It only
states the converse.) How about a clarification like this:
@@ -271,7 +271,10 @@ <title id="sql-declare-notes-title">Notes</title>
and not use grouping or <literal>ORDER BY</literal>). Cursors
that are not simply updatable might work, or might not, depending on plan
choice details; so in the worst case, an application might work in testing
- and then fail in production.
+ and then fail in production. If <literal>FOR UPDATE</literal> is
+ specified, then the cursor is guaranteed to be updatable, or the
+ <command>DECLARE</command> command will error if an updatable cursor
+ cannot be created for the supplied query.
</para>
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-05-10 16:55:23 | Re: updatable cursors and ORDER BY |
Previous Message | David G. Johnston | 2018-05-10 03:26:53 | Re: updatable cursors and ORDER BY |