On Mon, 2024-06-10 at 17:39 -0400, Tom Lane wrote:
> What I suggest is that we use int64 microseconds
> since the epoch, which is the same idea as the backend's TimestampTz
> except I think we'd better use the Unix epoch not 2000-01-01.
> Then converting code is just a matter of changing variable types
> and adding some zeroes to constants.
...
> Lastly, we need a way to get current time in this form. My first
> draft of the attached patch had the callers calling gettimeofday
> and doing arithmetic from that, but it seems a lot better to provide
> a function that just parallels time(2).
I briefly skimmed the thread and didn't find the reason why the API
requires an absolute time.
My expectation would be for the last parameter to be a relative timeout
("wait up to X microseconds"). That avoids the annoyance of creating a
new definition of absolute time and exposing a new function to retrieve
it.
Regards,
Jeff Davis