Re: updateable cursors & visibility

Hiroshi Inoue kirjutas E, 31.03.2003 kell 19:08:
> > -----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.

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