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.
