Re: libpq bad async behaviour

On 14 January 2015 at 08:40, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:

> I think that kind of solution isn't likely to be satisfying. The amount
> of porting work is just not going to be worth the cost. And it won't be
> easily hideable in the API at all as the callers will expect a normal
> fd.
>

All that consumers of the API need is something they can `select()` or
equivalent on.

> > Yeah, this is a problem. Fixing it isn't easy, though, I think.
>
> I think
> extern PostgresPollingStatusType PQconnectPoll(PGconn *conn);
> has the right interface. It returns what upper layers need to wait
> for. I think we should extend pretty much that to more interfaces.

This would be a fine solution. That enum indeed has the correct
values/semantics.

> This
> likely means that we'll need extended versions of PQFlush() and
> PQconsumeInput() - afaics it shouldn't be much more?
>

PQping?
PQconnectPoll already has it.

Though, I think we could probably even reduce this down to a single common
function for all cases:
PQpoll() or similar.