Re: Parameters don't work in FETCH NEXT clause?

From: Shay Rojansky <roji(at)roji(dot)org>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parameters don't work in FETCH NEXT clause?
Date: 2016-05-17 21:23:26
Message-ID: CADT4RqD=GaWMqbYbos_BWyrzapY5OvN=X05nASdoa2hWGkzGxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> ​Would something like this be valid?
>
> OFFSET { start_literal | ( start_expression ) } { ROW | ROWS }
> FETCH { FIRST | NEXT} [ count_literal | ( count_expression ) ] { ROW |
> ROWS } ONLY
>
> Leaving the mandatory parentheses detail to the description, while
> adequate, seems insufficient - especially when a normal LIMIT expression is
> not so restricted.
>
> ​And don't you think the section header would be more accurately named:
>
> Limit, Offset & Fetch Clauses
>
> ​The nuance regarding "different standard syntax" is unknown to the reader
> who first looks at the syntax and sees three different lines, one for each
> clause, and then scrolls down looking at headers until they find the
> section for the clause they are interested in. That FETCH is an alias for
> LIMIT ​is not something that I immediately understood - though to be honest
> I don't think I comprehended the presence of FETCH on a SELECT query at all
> and thought it only pertained to cursors....
>
>
All these suggestions would definitely have saved me (and therefore this
list!) some time.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2016-05-17 21:32:38 Re: Reviewing freeze map code
Previous Message Tom Lane 2016-05-17 21:02:42 Re: seg fault in contrib/bloom