Hi,
Tatsuo Ishii <t-ishii@sra.co.jp> wrote:
>
> 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.
This plan is welcome !
> 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.
Do those changes mean that libpq(or psql) always has the MULTIBYTE
function?
Now, libpq's MULTIBYTE function is a compile option(--with-mb).
But, I always want the MULTIBYTE function, even if PostgreSQL have
*not* been made with "--with-mb" option. Because, I want to access
two kind of PostgreSQL servers(named A and B) by using the B's psql.
(Here, A server is "--with-mb" and B server is not "--with-mb".)
Regards,
SAKAIDA Masaaki -- Osaka, Japan