Re: NEXT VALUE FOR <sequence>

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <munro(at)ip9(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: NEXT VALUE FOR <sequence>
Date: 2014-10-02 23:18:48
Message-ID: 6116.1412291928@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <munro(at)ip9(dot)org> writes:
> On 2 October 2014 14:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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].

Wow, it was that far back? No wonder I didn't remember the details.

> I suppose one approach would be to use command
> IDs as the scope.

The spec clearly says one value per row, not one per statement; so
command ID is very definitely not the right thing.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2014-10-02 23:38:24 Re: DDL Damage Assessment
Previous Message Marti Raudsepp 2014-10-02 23:15:27 Re: CREATE IF NOT EXISTS INDEX