Thread

Re: [PATCH] Generate random dates/times in a specified range

Dean Rasheed <dean.a.rasheed@gmail.com> — 2025-09-08T12:40:57Z

On Tue, 26 Aug 2025 at 15:17, Damien Clochard <damien@dalibo.info> wrote:
>
> Le 25.08.2025 15:33, Greg Sabino Mullane a écrit :
> > Your v3 did not get attached to the previous email.
>
> My bad, here it is

It seems like we have reached a consensus on adding just the random
date and timestamp[tz] functions, so I took a more detailed look with
an aim to committing this.

I'm attaching v4 with a few minor updates:

1). Updated the paragraph of text below "Table 9.6. Random Functions"
to also refer to "Table 9.33. Date/Time Functions", so that it's clear
that all the comments that follow apply to the date/time random()
functions too -- in particular, the part about setseed(). Having
reflected on it, I think that's a slightly better option than putting
the new functions in Table 9.6, because that's part of a whole section
about mathematical functions and everything there refers to number
types, not dates/timestamps, so putting the new functions there feels
a little out-of-place.

2). Changed check_range_boundaries() to a macro CHECK_RANGE_BOUNDS().
This feels a little neater, since it's such a trivial check, and the
datatype is not always int64.

3). Changed the C function names, adding an underscore for better
readability and consistency with other date/timestamp functions.

4). Used the DATE/TIMESTAMP_IS_NOBEGIN/NOEND() macros for neatness.

5). I didn't like this error message:

ERROR:  lower and upper bound cannot be infinite

because it's not grammatically correct, so I changed it to this:

ERROR:  lower and upper bounds must be finite

which is an error already used elsewhere for similar checks. This is
not quite the same as the errors thrown by random_numeric() -- perhaps
that should be changed to match (making its errors the same as the
errors thrown by width_bucket_numeric()).

6). It's not necessary to include utils/builtins.h or utils/datetime.h.

I think this is now committable, so if there are no objections, I'll
push this shortly.

Regards,
Dean