Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) - Mailing list pgsql-committers

From Hiroshi Inoue
Subject Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Date
Msg-id 39F8F763.1A47D9C1@tpf.co.jp
Whole thread Raw
In response to pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)  (Tom Lane <tgl@postgresql.org>)
List pgsql-committers

Tom Lane wrote:

> Hiroshi Inoue <Inoue@tpf.co.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.



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Next
From: Hiroshi Inoue
Date:
Subject: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)