Libpq API Weaknesses
From PostgreSQL wiki
Revision as of 01:13, 28 July 2019 by Andresfreund (Created page with "In case somebody has time to address some of these... * PQconsumeInput() does not return whether any data input (or output in case of nonblocking connections) has been consu...")
In case somebody has time to address some of these...
- PQconsumeInput() does not return whether any data input (or output in case of nonblocking connections) has been consumed. That means that more complex state machines need to be built around it.
- Whether libpq currently is is waiting for writes or reads is not exposed. There's PostgresPollingStatusType, which is returned by PQconnectPoll()/PQresetPoll(), but we don't conveniently expose it during normal operation. That's especially problematic for PQsend*, where it's entirely unclear whether reading or writing is needed. One can approximate it it by calling PQflush().
- The query result format can only be set on a per-query basis, not on a per-column/per type basis, even though the protocol supports the former. That's annoying because users need to add support for every type possibly used to benefit from the binary protocol, even though even just supporting a handful (bytea in particular) reaps most of the benefit.
- no pipelined query support
- Lots of old deprecated functions