Re: updateable cursors & visibility - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: updateable cursors & visibility
Date
Msg-id 001601c2f79f$d2eb1e40$0e283ddb@PbgX
Whole thread Raw
In response to Re: updateable cursors & visibility  (Hannu Krosing <hannu@tm.ee>)
Responses Re: updateable cursors & visibility
List pgsql-hackers
> -----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.
> 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: A few questions:
Next
From: "John Liu"
Date:
Subject: 7.3.2 make failed on AIX4.3 using native c compiler