Re: cursor sensitivity misunderstanding

On Thu, Feb 25, 2021 at 8:37 AM Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:

> On 18.02.21 19:14, Peter Eisentraut wrote:
> > On 18.02.21 17:11, David G. Johnston wrote:
> >> The OP was doing a course based on Oracle and was confused regarding
> >> our behavior. The documentation failed to help me provide a useful
> >> response, so I'd agree there is something here that needs reworking if
> >> not outright fixing.
> >
> > According to the piece of the standard that I posted, the sensitivity
> > behavior here is implementation-dependent (not even -defined), so both
> > implementations are correct.
> >
> > But the poster was apparently also confused by the same piece of
> > documentation.
>
> I came up with the attached patch to sort this out a bit. It does not
> change any cursor behavior. But the documentation now uses the terms
> more correctly and explains the differences between SQL and the
> PostgreSQL implementation better, I think.
>

thanks!, though this seems like the wrong approach. Simply noting that our
cursor is not standard compliant (or at least we don't implement a
standard-compliant sensitive cursor) should suffice. I don't really get
the point of adding ASENSITIVE if we don't have SENSITIVE too. I'm also
unfamiliar with the standard default behaviors to comment on where we
differ there - but that should be easy enough to address.

I would suggest limiting the doc change to pointing out that we do allow
for a standard-compliant INSENSITIVE behaving cursor - one that precludes
local sensitively via the FOR SHARE and FOR UPDATE clauses - by adding that
keyword. Otherwise, while the cursor is still (and always) insensitive
globally the cursor can become locally sensitive implicitly by including a
FOR UPDATE or FOR SHARE clause in the query. Then maybe consider improving
the notes section through subtraction once a more clear initial
presentation has been made to the reader.

David J.