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
signature.asc
Description: PGP signature
