Re: updateable cursors & visibility

> -----Original Message-----
> From: Hannu Krosing [mailto:hannu(at)tm(dot)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