Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Hiroshi Inoue writes:
> >> Must a SENSITIVE cursor see other applications' changes made
> >> while the cursor is open ?
> > Yes. It is immaterial whether the change came from a different
> > application or the same one.
> > Nevertheless, the cursor sensitivity does not excuse you from observing
> > the transaction isolation level. So even if the cursor is sensitive you
> > should not be able to see other transactions' changes if you are in a
> > serializable transaction.
>
> Serializable or not, there is a good case for saying that cursors don't
> see changes made after they are opened, period. The current
> implementation locks down the cursor's snapshot at DECLARE time.
It's only because PostgreSQL( or other MVCC based DBMS) is
easy and natural to implement cursors in such a way. However,
It isn't a requirement of the SQL standard, IIRC.
As for ODBC, ODBC has the following cursor types about the
visibility of other changes.
1) static
It never detects other changes.
2) dynamic
It can detect any changes made to the membership, order,
and values of the result set after the cursor is opened.
3) keyset-driven
It always detects changes to the values of rows.
4) mixed
A combination of a keyset-driven cursor and a dynamic
cursor.
It's not clear to me now how we should realize the above
type of cursors at server side.
regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
