From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: support for NEXT VALUE FOR expression |
Date: | 2016-08-17 04:32:02 |
Message-ID: | 19795.1471408322@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> Here is a patch for implementing the NEXT VALUE FOR expression. This is
> the SQL-standard conforming version of our nextval() function, and it's
> also used by Oracle, MS SQL, DB2.
BTW, several of the earlier threads complained of needing to make NEXT
a fully-reserved word in order to get this to parse without shift/reduce
conflicts. How did you avoid that? I notice that your patch puts the
new production into c_expr not func_expr_common_subexpr which would
seem like the obvious place. If that is what's making the difference
it seems rather fragile, and it would mean that NEXT VALUE FOR doesn't
act like a function in some syntactic contexts like a FROM-function.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Venkata B Nagothi | 2016-08-17 04:33:49 | Re: patch proposal |
Previous Message | Tom Lane | 2016-08-17 04:19:21 | Re: support for NEXT VALUE FOR expression |