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