On 3 October 2014 00:01, Thomas Munro <mu...@ip9.org> wrote: > On 2 October 2014 14:48, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Thomas Munro <mu...@ip9.org> writes: >>> SQL:2003 introduced the function NEXT VALUE FOR <sequence>. Google >>> tells me that at least DB2, SQL Server and a few niche databases >>> understand it so far. As far as I can tell there is no standardised >>> equivalent of currval and setval (but I only have access to second >>> hand information about the standard, like articles and the manuals of >>> other products). >> >> Have you checked the archives about this? My recollection is that one >> reason it's not in there (aside from having to reserve "NEXT") is that >> the standard-mandated semantics are not the same as nextval(). > > Right, I found the problem: "If there are multiple instances of <next value > expression>s specifying the same sequence generator within a single > SQL-statement, all those instances return the same value for a > given row processed by that SQL-statement." This was discussed in a thread > from 2002 [1]. > > So the first step would be to make a standard conforming function to transform > the standard's syntax into. > > I found the text in the 20nn draft specification and it didn't seem > immediately > clear what 'statement' should mean, for example what if your statement calls > pl/pgsql which contains further statements, and what if triggers, default > expressions, etc are invoked? I suppose one approach would be to use command > IDs as the scope. Do you think the following change would make sense? > > In struct SeqTableData (from sequence.c), add a member last_command_id. > When you call the new function, let's say nextval_for_command(regclass), > if last_command_id matches GetCommandId() then it behaves like currval_oid > and returns last, otherwise it behaves like nextval_oid, and updates > last_command_id to the current command ID.
Actually scratch that, it's not about statements, it's about "rows processed by that SQL-statement". I will think about how that could be interpreted and implemented... Best regards, Thomas Munro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers