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 00:09:33
Message-ID: 39F8C7BD.6606A39D@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:
> >> Re-implement LIMIT/OFFSET as a plan node type, instead of a hack in
> >> ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a
> >> cursor declaration will behave in a reasonable fashion,
>
> > Does "reasonable" mean that LIMIT is treated as optimizer's
> > hint but doesn't restrict total FETCH counts ?
>
> No, it means that a LIMIT in a cursor means what it says: the cursor
> will show that many rows and no more. FETCH lets you move around in
> the cursor, but not override the limit. I decided that the other
> behavior was just too darn weird... if you want to argue about that,
> let's take it up on pghackers not committers.
>
> Yes, the optimizer does pay attention to the limit.
>

Hmm,I'm not sure about your point.
Please correct me if I'm misunderstanding.

We can specify rows count by FETCH command.
It seems to me that LIMIT in declare cursor statement is only
for optimizer's hint.

Regards.
Hiroshi Inoue

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2000-10-27 00:17:23 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Previous Message Tom Lane 2000-10-26 23:49:52 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 00:17:23 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Previous Message Tom Lane 2000-10-26 23:49:52 Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)