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