Re: [HACKERS] libpq+MB/putenv(), getenv() clean up - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
Date
Msg-id Pine.GSO.4.02A.10001131154340.6438-100000@Pingvin.DoCS.UU.SE
Whole thread Raw
In response to libpq+MB/putenv(), getenv() clean up  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: [HACKERS] libpq+MB/putenv(), getenv() clean up
List pgsql-hackers
On Thu, 13 Jan 2000, Tatsuo Ishii wrote:

> 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())

Whatever you do, please do not set any environment variables from within
programs. It's evil. Consider the user leaving the database and connecting
to another, but then PGCLIENTENCODING is already set to what would be
interpreted as his "preference", but maybe he wants the backend to decide.
I saw you had some hacks in psql for working around this, but psql is not
every application. I think what you are suggesting below would incorporate
this change, I just want to express it explicitly.

> 
> (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.

How about PQencoding()?

> 
> (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.

How about PQmblen(character, encoding)? Then you could call it PQmblen(c,
PQclientencoding(conn)) or PQmblen(c, other_encoding). That makes it more
general.

> 
> (5) Change fe-print.c:do_filed() to add an argument which is a pointer to
> PGconn.
> 
> Comments and suggestions are welcome.
> --
> Tatsuo Ishii
> 
> ************
> 
> 

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: [HACKERS] TODO list updated
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] TODO list updated