On 5/28/18 13:17, Bruce Momjian wrote:
> On Thu, May 10, 2018 at 12:55:23PM -0400, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> 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>
>>
>> OK by me, except we don't usually use "error" as a verb. Either "fail"
>> or "throw an error" would read better IMO. Or you could just stop with
>> "guaranteed to be updatable"; I don't think the rest adds much.
>
> I have done as you suggested and just used the first part; patch
> attached and backpatched.
I think we should still add the second part, because it currently
doesn't say anything about that a cursor declaration might fail if an
updatable cursor cannot be created.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services