Re: MOVE LAST: why?

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: MOVE LAST: why?
Date: 2003-01-09 03:18:48
Message-ID: 3E1CEA18.18E921A0@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> 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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Mount 2003-01-09 13:45:45 Re: psql and readline
Previous Message Bruce Momjian 2003-01-09 02:25:55 Re: ipv6 build error?

Browse pgsql-interfaces by date

  From Date Subject
Next Message Key88 SF 2003-01-09 06:29:02 Re: libpqxx Large Objects
Previous Message Jeroen T. Vermeulen 2003-01-09 02:34:43 Re: libpqxx Large Objects