Re: Extended SERIAL parsing

Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu> writes:
> Tom Lane rta:
>> You're missing the hard part: NEXT VALUE FOR is sufficiently different
>> from nextval() that it will be very painful to implement.

> Do you mean the allowed and denied contexts of the
> NEXT VALUE FOR expression in section 6.13?

No, I mean that different textual instances of NEXT VALUE FOR are
required to return the same value in certain cases. See the "once per
row" bits in the 6.13 General Rules. It's not real clear what "once per
row" actually means, especially in cases such as references from within
functions invoked by a query --- is that the same query or a different
one? You could make a case for wanting either behavior, particularly
when considering trigger functions. On the whole, it's a mess, and not
particularly well thought out IMHO. But it's in the spec, and if we are
going to adopt the spec's syntax for identity columns then we'd better
provide the spec's behavior.

> (As opposed to nextval() which, as being a function
> is allowed more broadly.) This part may still be described
> with grammar, unless you mean something more suble.

I think trying to enforce the restrictions in 6.13 in the grammar
would be a terrible mistake; better to do it in parse analysis.
Compare the restrictions on where aggregate functions can appear;
we don't try to enforce those grammatically. One reason why not
is that you'd have a hard time getting the grammar to produce anything
more specific than "syntax error", which is pretty unhelpful.

regards, tom lane