Re: NEXT VALUE FOR <sequence>

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Thomas Munro <munro(at)ip9(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: NEXT VALUE FOR <sequence>
Date: 2014-10-02 11:27:43
Message-ID: 542D36AF.8070000@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/01/2014 07:28 PM, Thomas Munro wrote:
> Hi
>
> 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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-10-02 11:47:33 Re: pgcrypto: PGP signatures
Previous Message Ilya Kosmodemiansky 2014-10-02 11:22:32 Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)