On Thu, Jul 6, 2023 at 9:00 AM Jacob Champion <jchamp...@timescale.com> wrote: > My goal is to maintain compatibility with existing PQconnectPoll() > applications, where the only way we get to communicate with the client > is through the PQsocket() for the connection. Ideally, you shouldn't > have to completely rewrite your application loop just to make use of > OAuth. (I assume a requirement like that would be a major roadblock to > committing this -- and if that's not a correct assumption, then I > guess my job gets a lot easier?)
Ah, right, I get it. I guess there are a couple of ways to do it if we give up the goal of no-code-change-for-the-client: 1. Generalised PQsocket(), that so that a client can call something like: int PQpollset(const PGConn *conn, struct pollfd fds[], int fds_size, int *nfds, int *timeout_ms); That way, libpq could tell you about which events it would like to wait for on which fds, and when it would like you to call it back due to timeout, and you can either pass that information directly to poll() or WSAPoll() or some equivalent interface (we don't care, we just gave you the info you need), or combine it in obvious ways with whatever else you want to multiplex with in your client program. 2. Convert those events into new libpq events like 'I want you to call me back in 100ms', and 'call me back when socket #42 has data', and let clients handle that by managing their own poll set etc. (This is something I've speculated about to support more efficient postgres_fdw shard query multiplexing; gotta figure out how to get multiple connections' events into one WaitEventSet...) I guess there is a practical middle ground where client code on systems that have epoll/kqueue can use OAUTHBEARER without any code change, and the feature is available on other systems too but you'll have to change your client code to use one of those interfaces or else you get an error 'coz we just can't do it. Or, more likely in the first version, you just can't do it at all... Doesn't seem that bad to me. BTW I will happily do the epoll->kqueue port work if necessary.
