> -----Original Message-----
> From: Hannu Krosing [mailto:[EMAIL PROTECTED] 
> 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
there were no such reference in this thread.

Hiroshi Inoue

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to