On 09.03.21 00:22, David G. Johnston wrote:
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
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
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
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
On Thu, Feb 18, 2021 at 9:00 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> And that seems definitely wrong. Declaring c1 in the above example as
> FOR UPDATE or FOR SHARE does not change the result. I think this
> discussion is mixing up the concept of cursor sensitivity
I think our documentation is mistaken about what it means for a cursor
to be "sensitive" or "insensitive".
The definition in SQL:2016 is:
A change to SQL-data is said to be independent of a cursor CR if and
only if it is not made by an or a
that is positioned on CR.
A
