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 |
Message-ID: | YuTb4w06YMZbB0HX@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
--
Michael
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 |