Tom:
On Tue, 11 Jun 2024 at 01:49, Tom Lane wrote:
> I think if we're going to change anything at all here, we should
> define the external API in microseconds not milliseconds. The lesson
> we need to be taking from this is that system calls come and go,
> but libpq API is forever ;-). Somebo
Thomas Munro writes:
> On Tue, Jun 11, 2024 at 2:36 AM Dominique Devienne
> wrote:
>> PQsocketPoll() being based on time_t, it has only second resolution, AFAIK.
>> Despite the [underlying implementation in fe-misc.c][2] supporting at
>> least milliseconds.
> Yeah, that is not nice and your com
On Tue, Jun 11, 2024 at 2:36 AM Dominique Devienne wrote:
> Hi. I've noticed [that libpq API in v17 beta1][1], and wanted to use
> it to replace an existing Boost.ASIO-based async polling of the
> connection's socket, waiting for notifications. The use case being
> using PostgreSQL LISTEN/NOTIFY f
On 6/10/24 11:43, Dominique Devienne wrote:
Bummer… I didn’t presume to suggest an api before, but simply adding an
extra int with the milliseconds offset from the time_t is simple, and
trivial to plug into the implementation I saw. Callers who don’t care
can simply pass zero. while I could pas
Bummer… I didn’t presume to suggest an api before, but simply adding an
extra int with the milliseconds offset from the time_t is simple, and
trivial to plug into the implementation I saw. Callers who don’t care can
simply pass zero. while I could pass a computed time_t and ms offset using
. No nee
Dominique Devienne writes:
> PQsocketPoll() being based on time_t, it has only second resolution, AFAIK.
> Despite the [underlying implementation in fe-misc.c][2] supporting at
> least milliseconds.
> ...
> But I think it would a pity if that unreleased API couldn't be made to
> accomodate sub-sec
