Re: NEXT VALUE FOR sequence

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

Tom Lane wrote:
> 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.

Would it be reasonable to say that any two NextValueExpr in the same
target list are "in one row"?

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus de Oliveira 2018-02-20 15:10:22 [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT
Previous Message Aleksander Alekseev 2018-02-20 15:08:38 [PATCH] Add a few suppression rules for Valgrind