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
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) |