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
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 |