From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | lukas(dot)eder(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15200: Support ANSI OFFSET .. FETCH syntax with bind variables |
Date: | 2018-05-19 20:57:44 |
Message-ID: | 87bmdb4d12.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> "PG" == PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
PG> And as shown in this Stack Overflow question [2], it can be shown
PG> that the standard syntax doesn't work with anything but constant
PG> literals, including bind variables (which to me, are a kind of
PG> constant literal).
This does seem to be a defect in the code - the comments in the parser
say that the spec only allows constants, which is clearly wrong (what
the spec actually allows is <simple value specification>, which is
either a literal or a parameter/host variable/embedded variable).
PG> This is regrettable, the workaround when using this syntax from
PG> Java is to write:
PG> OFFSET (?) ROWS FETCH FIRST (?) ROWS ONLY
Having to use a workaround rather defeats the point of supporting
standard syntax in the first place. :-(
PG> This is also inconsistent with OFFSET .. LIMIT. The following works
PG> just fine:
PG> OFFSET ? LIMIT ?
This syntax doesn't have trailing ROW or ROWS keywords to contend with,
so it can allow arbitrary expressions without confusing the parser.
PG> I suggest relaxing this syntactic limitation and allowing for at
PG> least constant literals AND bind variables in this syntax
I think this is fixable with a fairly simple tweak to gram.y. The tricky
part is that FETCH FIRST allows the expression to be omitted entirely,
which causes shift/reduce conflicts (if we see ROW, is that the first
token in the expression, or an empty expression?). But since ONLY is a
fully reserved word, I think this can be solved by splitting into two
productions (one with the expression and one without), since by the time
we need to decide whether to reduce ROW/ROWS to anything, we can see
whether ONLY is the lookahead token.
Going to poke at this a bit to see if I can make it work right.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-05-19 22:34:26 | Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT |
Previous Message | David G. Johnston | 2018-05-19 19:05:09 | Re: BUG #15206: Can not import CSV into PostgreSQL |