Peter Eisentraut <> 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to