On Thu, Oct 2, 2014 at 7:27 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
>> SQL:2003 introduced the function NEXT VALUE FOR <sequence>. Google
>> tells me that at least DB2, SQL Server and a few niche databases
>> understand it so far. As far as I can tell there is no standardised
>> equivalent of currval and setval (but I only have access to second
>> hand information about the standard, like articles and the manuals of
>> other products).
>>
>> Here is a starter patch to add it. To avoid a shift/reduce conflict,
>> I had to reclassify the keyword NEXT. I admit that I don't fully
>> understand the consequences of that change! Please let me know if you
>> think this could fly.
>
> Looks correct. Of course, it's annoying to have to reserve the NEXT keyword
> (as a type_func_name_keyword, not fully reserved).
>
> One way to avoid that is to collapse NEXT VALUE FOR into a single token in
> parser.c. We do that for a few other word pairs: NULLS FIRST, NULLS LAST,
> WITH TIME and WITH ORDINALITY. In this case you'd need to look-ahead three
> tokens, not two, but I guess that'd be doable.
Those kinds of hacks are not scalable. It's not too bad right now
because NULLS, FIRST, and LAST are all rarely-used keywords and
there's rarely a reason for FIRST and LAST to follow NULLS except in
the exact context we care about. But the more we extend those hacks,
the more likely it is that the lexer will smash the tokens in some
case where the user actually meant something else. Hacking the lexer
to get around grammar conflicts doesn't actually fix whatever
intrinsic semantic conflict exists; it just keeps bison from knowing
about it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company