From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Solution for LIMIT cost estimation |
Date: | 2000-02-16 22:34:43 |
Message-ID: | 3.0.5.32.20000217093443.03588e50@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 10:43 16/02/00 -0500, Tom Lane wrote:
>Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>>> A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as
>>> being simply a hint to the optimizer about how much of the query
>>> result will actually get fetched.
>
>> This seems a good approach until cursors are fixed. But is there a plan to
>> make cursors support LIMIT properly? Do you know why they ignore the LIMIT
>> clause?
>
>Should they obey LIMIT? MOVE/FETCH seems like a considerably more
>flexible interface, so I'm not quite sure why anyone would want to
>use LIMIT in a cursor.
I agree; but see below.
>Still, it seems kind of inconsistent that cursors ignore LIMIT.
>I don't know for sure why it was done that way.
It's the inconsistency that bothers me: if I run a SELECT statement, then
put it in a cursor, I should get the same rows returned. Ths current
behaviour should probably be considered a bug.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2000-02-16 23:00:42 | pgaccess and multibyte-enabled libpq |
Previous Message | Bruce Momjian | 2000-02-16 22:29:33 | Re: [HACKERS] FYI: BNF for SQL93 and SQL-3 |