This seems like a rather elegant concept. There isn't any direct request-response structure, but rather a streaming communications pattern. And it's easy to throttle the requests by implementing a bounded communication channel between the muxer and demuxer. But as it stands, I appear to have run into a roadblock I can't get around. I don't know how to write the demuxer so that it responds to both asynchronous notifications and client-side disconnects in a timely fashion. Asynchronous exceptions would be a possibility, but that is playing with fire. I could spin up another thread, but there are more appealing three-thread solutions. Interestingly enough, if Postgres would delay hanging up a connection after receiving a Terminate 'X' message until it's finished responding to any requests that have already been received, then I don't think this concept would have any problem. The muxer could signal the demuxer about the disconnect by going through the database itself. It's probably worth testing at some point if Postgres does this, but wulczer on the #postgresql channel looked at postgres.c and said it appeared as though it would immediately hang up. It might be interesting to patch PostgreSQL to support this behavior, and see if there is any advantage.
…or PostgreSQL types.
…builds without the mysql dependency.