Enables syntax: NEXT VALUE FOR <seqname> and CURRENT VALUE FOR <seqname>
The 200N spec is based on DB2, not MSSQL, so it is very likely NEXT
VALUE FOR will be the official syntax.
http://216.239.37.100/search?q=cache:s5eWP72lHKcJ:www7b.software.ibm.com/dmdd/library/techarticle/0302fielding/0302fielding.html+%22Bobby+Fielding%22+&hl=en&lr=lang_en&ie=UTF-8
DB2 uses PREVIOUS VALUE FOR <seqname> as their currval() (nothing in
spec about this). I don't see PREVIOUS as a reserved word, but CURRENT
certainly is -- WHERE CURRENT OF for cursors, and several other places.
The attached patch makes CURRENT a reserved word. VALUE is treated as
an IDENT to preserve the ability to use it as a column.
SequenceOp is the node (primnode) used in the executor, and required
splitting up nextval / currval into public and internal interfaces. The
internal interface operates on the sequence OID, and the public
interface on the sequence name as usual.
Dependencies are recorded for the SequenceOp node so now we cannot drop
a sequence used in a default expression.
I've not figured out the best place to record the dependency to prevent
the default expression from being changed for SERIAL columns yet, but
that should be a separate patch. The concept of a serial will need to
be brought in deeper than parser/analyze.c for this to happen.
No documentation changes attached. I want to know whether this would be
applied before I make those.
Tom,
Should I have created another parser node strictly for the gram.y stuff,
then had it copy the info to the primnode within parse_expr.c? As it
is, SequenceOp is left with a hanging RangeVar that is unused past that
point.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc