Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT.... - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....
Date
Msg-id 20010910155046Q.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
> > Why? set_default_client_encoding does the job anyway.
>
>  Here can't be used static default encoding as for DatabaseEncoding, because
> typical code is
>
>  if (!ClientEncoding)
>     /* ...means "if user doesn't set itself client
>      * encoding by SET command"
>      */
>     ClientEncoding = DatabaseEncoding;
>
>  and if you set anywhere before this as default
> ClientEncoding = &pg_enc2name_tbl[ PG_SQL_ASCII ]; the ClientEncoding will
> always TRUE and always SQL_ASCII and the only way is change it by 'SET
> CLIENT_ENCODING' command. But we don't want it, wanted is after connection
> set as default ClientEncoding same encoding as actual DabaseEncoding.

Don't worry about that. Before anything user could do, postgres's
start up procedure sets the appropreate encoding to ClientEncoding
variable.

Also please note that "wanted is after connection set as default
ClientEncoding same encoding as actual DabaseEncoding" is not
corrent. The ClientEncoding might be set differently if
PGCLIENTENCODING is set before postmaster starts up.
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: COMMENT ON
Next
From: Karel Zak
Date:
Subject: Re: [PATCHES] CURRENT CVS: MULTIBYTE: CANT CONNECT....