On 14 January 2015 at 08:40, Andres Freund <and...@2ndquadrant.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.
