Re: NEXT VALUE FOR sequence

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: NEXT VALUE FOR sequence
Дата
Msg-id 1519139397.2482.13.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: NEXT VALUE FOR sequence  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: NEXT VALUE FOR sequence
Список pgsql-hackers
Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: [PATCH] Add a few suppression rules for Valgrind
Следующее
От: Matheus de Oliveira
Дата:
Сообщение: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT