Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> i extracted the functions to connect that Heikki put on psql in his
> patch for determining client_encoding from client locale and put it in
> libpq so i follow the PQconnectdbParams(* params[]) approach.

I got around to looking at the actual patch a bit. I hadn't understood
why it was so small, but now I do: it's implemented as a wrapper around
PQconnectdb. That is, it takes the given keywords and values, and
builds a conninfo string, which PQconnectdb then has to pull apart
again. This seems, well, dumb. I'll admit that the wasted cycles are
probably not much compared to all the other costs of establishing a
connection. But it means that you're still exposed to all the other
limitations of PQconnectdb, eg any possible bugs or restrictions in the
quoting/escaping logic. It seems to me that a non-bogus patch for this
would involve refactoring the code within PQconnectdb so that the
keywords and values could be plugged in directly without the escaping
and de-escaping logic. It doesn't look that hard to pull apart
conninfo_parse into two or three functions that would support this.

Another reason why it needs refactoring is that this way doesn't expose
all the functionality that ought to be available; in particular not the
ability to do an async connection while passing the parameters in this
style. You need analogs to PQconnectStart and PQconnectPoll too.
(Actually I guess the existing PQconnectPoll would work fine, but you
definitely need an analog to PQconnectStart.)

regards, tom lane