Hiroshi Inoue kirjutas E, 31.03.2003 kell 19:08: > > -----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.
In what way would the _changes_made_to_the_order_ be reflected then ? > > 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. It seems to be doable with MVCC - "just" ;) check for visibility of underlying tuples at each fetch. At least it does not seem any harder for MVCC than for other CC methods. > > > > 3) keyset-driven > > > It always detects changes to the values of rows. > > > > What about _new_ rows, > > It never detects new rows. Then I must have misunderstood the "can detect any changes made to the membership, order, and values" part. I assumed that "any changes" wold also include rows that magically become part of the query by either changes in values or being inserted. > > or rows that no more belong to the "keyset" ? > > They are the same as deleted ones. So they are no more visible to cursor ? > > >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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
