Re: FETCH FIRST clause WITH TIES option
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Surafel Temesgen <surafel3000@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-04-08T02:01:33Z
Lists: pgsql-hackers
>>>>> "Alvaro" == Alvaro Herrera <alvherre@2ndquadrant.com> writes: Alvaro> It turns out that the SQL standard is much more limited in what Alvaro> it will accept there. But our grammar (what we'll accept for Alvaro> the ancient LIMIT clause) is very lenient -- it'll take just Alvaro> any expression. I thought about reducing that to NumericOnly Alvaro> for FETCH FIRST .. WITH TIES, but then I have to pick: 1) Alvaro> gram.y fails to compile because of a reduce/reduce conflict, or Alvaro> 2) also restricting FETCH FIRST .. ONLY to NumericOnly. Neither Alvaro> of those seemed very palatable. FETCH FIRST ... ONLY was made _too_ restrictive initially, such that it didn't allow parameters (which are allowed by the spec); see 1da162e1f. (That change didn't present a problem for ruleutils, because FETCH FIRST ... ONLY is output as a LIMIT clause instead.) This needs to be fixed in ruleutils, IMO, not by changing what the grammar accepts. -- Andrew.
Commits
-
Support FETCH FIRST WITH TIES
- 357889eb17bb 13.0 landed