On Thu, 8 Jul 2021 at 09:26, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > > Finally, I think it would be better to treat the upper bound of the > > range as inclusive. > > This bothered me as well, but the usual approach seems to use range as the > number of values, so I was hesitant to depart from that. I'm still > hesitant to go that way. >
Yeah, that bothered me too. For example, java.util.Random.nextInt(bound) returns a value in the range [0,bound). But other implementations are not all like that. For example python's random.randint(a,b) returns a value in the range [a,b]. Python also has random.randrange(start,stop[,step]), which is designed for compatibility with their range(start,stop[,step]) function, which treats "stop" as exclusive. However, Postgres tends to go the other way, and treat the upper bound as inclusive, as in, for example, generate_series() and pgbench's random() function. I think it makes more sense to do it that way, because then such functions can work all the way up to and including the limit of the bound's datatype, which makes them more general. Regards, Dean
