libpq+MB/putenv(), getenv() clean up - Mailing list pgsql-hackers

Hi,

I have a plan to clean up the usage of putenv(), getenv() in libpq+MB
configuration. This needs some interface changes with libpq in the
frontend side. I'm not sure this is visible to end users or not, and I
would like to hear from hackes.

First of all, I would like to explain the current implementation.

(1) While establishing a connection, if the environment variable
PGCLIENTENCODING is not set, libpq asks the backend what the encoding
for the database is. This is done by sending a query "select
getdatabaseencoding()". In this case, both the backend and the
frontend uses same encoding and its name is set to the
PGCLIENTENCODING environment variable for the later use.
(fe-connect.c: PQsetenvPoll())

(2) When libpq prints the result of a query, it needs to determine the
length of a multi-byte letter. For this purpose, getenv() is called to
know the encoding name. (fe-print.c)

Above implementation has a design flaw since it is not multithread-safe.
To fix the problem, I would like to make changes as follows:

(1) Add a new member "int client_encoding" to struct pg_conn.

(2) Add an argument which is a pointer to PGconn to PQsetenvPoll() so
that the client encoding can be set in (1) above.

(3) Add a new function PQclientencoding() to extract client_encoding
from PGconn.

(4) Change PQmblen() so that it extracts encoding info using
PQclientencoding() rather than calling getenv(). This also requires
add an argument which is a pointer to PGconn.

(5) Change fe-print.c:do_filed() to add an argument which is a pointer to
PGconn.

Comments and suggestions are welcome.
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] TODO list updated
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] TODO list updated