On Thu, Feb 25, 2021 at 8:37 AM Peter Eisentraut < peter.eisentr...@enterprisedb.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.
