Hiroshi Inoue kirjutas E, 31.03.2003 kell 03:40:
> Tom Lane wrote:
> >
> > 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.
This seems the clearest ?
> 2) dynamic
> It can detect any changes made to the membership, order,
> and values of the result set after the cursor is opened.
What would it mean in practice, i.e. if you are on the first row in the
cursor and then update tha ORDER BY field so that your row becomes the
last one, will the next FETCH move the cursor past end ?
what happens, if the row you are on is removed from the keyset, either
by current or any other backend ?
What about the case when you have moved past the last row, and suddenly
a new row appears which is positioned after the last row ?
What about when you are moving over several rows that have the same
ordering position and then one more appears - should it go before or
after the current position ?
> 3) keyset-driven
> It always detects changes to the values of rows.
What about _new_ rows, or rows that no more belong to the "keyset" ?
> 4) mixed
> A combination of a keyset-driven cursor and a dynamic
> cursor.
Combined in what way ?
> It's not clear to me now how we should realize the above
> type of cursors at server side.
>From your short description it is not even clear for me how *exactly*
should they behave.
------------------
Hannu
