On 18.01.24 16:54, Matthias van de Meent wrote:
> At $prevjob we had a use case for PRNG to generate small,
> non-sequential "random" numbers without the birthday problem occurring
> in sqrt(option space) because that'd increase the printed length of
> the numbers beyond a set limit. The sequence API proposed here
> would've been a great alternative to the solution we found, as it
> would allow a sequence to be backed by an Linear Congruential
> Generator directly, rather than the implementation of our own
> transactional random_sequence table.
This is an interesting use case. I think what you'd need for that is
just the specification of a different "nextval" function and some
additional parameters (modulus, multiplier, and increment).
The proposed sequence AM patch would support a different nextval
function, but does it support additional parameters? I haven't found that.
Another use case I have wished for from time to time is creating
sequences using different data types, for example uuids. You'd just
need to provide a data-type-specific "next" function. However, in this
patch, all the values and state are hardcoded to int64.
While distributed systems can certainly use global int64 identifiers,
I'd expect that there would also be demand for uuids, so designing this
more flexibly would be useful.
I think the proposed patch covers too broad a range of abstraction
levels. The use cases described above are very high level and are just
concerned with how you get the next value. The current internal
sequence state would be stored in whatever way it is stored now. But
this patch also includes callbacks for very low-level-seeming concepts
like table AMs and persistence. Those seem like different things. And
the two levels should be combinable. Maybe I want a local sequence of
uuids or a global sequence of uuids, or a local sequence of integers or
a global sequence of integers. I mean, I haven't thought this through,
but I get the feeling that there should be more than one level of API
around this.
