Re: NEXT VALUE FOR sequence

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org, hs(at)cybertec(dot)at
Subject: Re: NEXT VALUE FOR sequence
Date: 2018-02-19 15:58:57
Message-ID: 6516.1519055937@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> The SQL standard has the expression "NEXT VALUE FOR asequence" to do
> what we traditionally do with "nextval('asequence')".
> This is an attempt to implement this on top of the recently introduced
> NextValueExpr node.

This has been proposed repeatedly, and rejected repeatedly, because in
fact the standard's semantics for NEXT VALUE FOR are *not* like nextval().
See SQL:2011 4.22.2 "Operations involving sequence generators":

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 is not terribly exact --- what is a "processed row" in a join query,
for instance? But it's certainly not supposed to act like independent
executions of nextval() or NextValueExpr would. Pending somebody doing
the legwork to produce something that at least arguably conforms to the
spec's semantics, we've left the syntax unimplemented.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-02-19 16:00:34 Re: autovacuum: change priority of the vacuumed tables
Previous Message Tom Lane 2018-02-19 15:43:03 Re: [PROPOSAL] Nepali Snowball dictionary