Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Date: 2000-10-27 03:32:51
Message-ID: 39F8F763.1A47D9C1@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Tom Lane wrote:

> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > For example,LIMIT ALL means LIMIT 1 for optimizer and means
> > no LIMIT for executor.
> > Comments ?
>
> I don't see the point. In the context of a regular SELECT, optimizing
> that way would be wrong, because we are going to fetch all the data.
> In the context of a DECLARE CURSOR, we already have a bias for fast-
> start plans, so why do we need another?
>

Hmm,I missed somthing ?
How would be the behavior of the following command sequence ?

begin;
declare myc cursor for select * from t1 limit 1;
fetch in myc;
fetch in myc;

Could the last fetch return a row ?

Regards, Hiroshi Inoue.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2000-10-27 03:36:19 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Previous Message Tom Lane 2000-10-27 03:14:14 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-10-27 03:36:19 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Previous Message Tom Lane 2000-10-27 03:14:14 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)