Sequence usage patch
От | Rod Taylor |
---|---|
Тема | Sequence usage patch |
Дата | |
Msg-id | 1054007443.52881.116.camel@jester обсуждение исходный текст |
Ответы |
Re: Sequence usage patch
Re: Sequence usage patch |
Список | pgsql-patches |
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
Вложения
В списке pgsql-patches по дате отправления: