> -----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 because there were no such reference in this thread. regards, Hiroshi Inoue ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
