Re: Support for grabbing multiple consecutive values with nextval()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jille Timmermans <jille(at)quis(dot)cx>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Support for grabbing multiple consecutive values with nextval()
Date: 2022-07-30 07:21:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jul 28, 2022 at 12:47:10PM -0400, Tom Lane wrote:
> Actually, on further thought, I do like the resultset idea, because
> it'd remove the need for a complex rewrite of nextval_internal.
> Assuming the SRF is written in ValuePerCall style, each iteration
> can just call nextval_internal with no modifications needed in that
> function. There'll be a CHECK_FOR_INTERRUPTS somewhere in the
> query-level loop, or at least it's not nextval's fault if there's not.
> The situation is then no different from generate_series with a large
> loop count, or any other query that can generate lots of data.
> Of course, this does imply a lot more cycles expended per generated value
> --- but most of that is inherent in the larger amount of data being
> handed back.

FWIW, I find the result set approach more intuitive and robust,
particularly in the case of a sequence has non-default values
INCREMENT and min/max values. This reduces the dependency of what an
application needs to know about the details of a given sequence. With
only the last value reported, the application would need to compile
things by itself.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-07-30 07:29:16 Re: Improve TAP tests of pg_upgrade for cross-version tests
Previous Message Michael Paquier 2022-07-30 07:14:33 Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger