> -----Original Message-----
> From: Hannu Krosing [mailto:hannu@tm.ee]
>
> Hiroshi Inoue kirjutas E, 31.03.2003 kell 03:40:
>
> > 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 ?
No. The row next to the old first row would be FETCHed.
> what happens, if the row you are on is removed from the keyset, either
> by current or any other backend ?
The dynamic cursor doesn't see the row any longer.
> 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 ?
The dynamic cursor would see the new row when it is fetched backwards.
> 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 ?
It is implementation dependent.
> > 3) keyset-driven
> > It always detects changes to the values of rows.
>
> What about _new_ rows,
It never detects new rows.
> or rows that no more belong to the "keyset" ?
They are the same as deleted ones.
> > 4) mixed
> > A combination of a keyset-driven cursor and a dynamic
> > cursor.
>
> Combined in what way ?
It uses a limited keyset size. If a fetch operation doesn't fit in
the range of the keyset, it dynamically fetches the result set.
> > 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.
I only intended to illustrate various type of visibilities roughly
because
there were no such reference in this thread.
regards,
Hiroshi Inoue
