Further to my discussions with Tom Lane on this list last weekend, I
have been re-arranging the connection functions in libpq to allow
asynchronous connections. Part of this has been to create new
functions that perform the duties of the existing function PQsetenv,
but in a non-blocking manner. This involves passing the values of
certain environment variables (PGDATESTYLE, PGTZ, et al) to the
backend, as well as negotiating a client encoding if MULTIBYTE is
defined. Now, PQsetenv is declared in fe-connect.c thus:
/* XXX Why is this not static? */
void PQsetenv(PGconn *conn);
It is not declared in libpq-fe.h, so currently those who are playing by
the rules are unable to call this function for themselves.
It seems to me that PQsetenv might be useful as part of the public API,
and I can see no harm in doing so. What is clear, however, is that the
functions I have created should have the same accessibility as
PQsetenv; to do otherwise would be nonsensical.
So, should I bring PQsetenv into the public API by declaring it in
libpq-fe.h, and have my functions join it, or should I keep the new
functions static (and probably leave PQsetenv non-static, with
compatibility worries). My preference would be the former - does anyone
disagree?
Ewan Mellor.