Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I'm suspicios if we should implement scrollable cursors
> > with the combination of the current MOVE and FETCH implemen-
> > tation. For example the backwards FETCH operation for group
> > nodes isn't implemented properly yet(maybe).
>
> Yeah, backwards scan is not implemented for quite a large number of plan
> node types :-(. I am not sure that it is practical to fix them all.
> I have been toying with the notion of making cursors on complex plans
> safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if
> the top plan node isn't one that can handle backwards scan.
>
> The trouble with this of course is that one of the main things people
> like to use cursors for is huge result sets, and materializing those is
> the last thing you want to do :-(
Honestly I'm not so enthusiastic about scrollable cursors.
Even though PostgreSQL provides an efficient scrollable
cursor, I would use it little unless it could survive
across transactions.
Anyway it's too bad that FETCH LAST means FETCH ALL.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
