Tom Lane wrote:
>
> Peter Eisentraut <peter_e@gmx.net> 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 Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/