To: cch@cc.kmu.edu.tw
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] A Patch for MIC to EUC_TW code converting inmbsupport
In-Reply-To: <3A11E40A.47E528D@cc.kmu.edu.tw>
References: <3A0FCEFA.42F0BABF@cc.kmu.edu.tw>
	<20001114145434O.t-ishii@sra.co.jp>
	<3A11E40A.47E528D@cc.kmu.edu.tw>
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
	boundary="--Next_Part(Fri_Nov_17_11:28:53_2000_809)--"
Content-Transfer-Encoding: 7bit
Message-Id: <20001117112855H.t-ishii@sra.co.jp>
Date: Fri, 17 Nov 2000 11:28:55 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Lines: 94

----Next_Part(Fri_Nov_17_11:28:53_2000_809)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > BTW I would not recommend "SET CLIENT_ENCODING TO 'BIG5'" to do an
> > on-the-fly encoding changes. Since in this way, frontend side has no
> > idea what the client encoding is. 7.0.x overcome this problem by
> > introducing new \encoding command. For 6.5 or before I would recommend
> > to use PGCLIENTENCODING environment variable.
> 
> You are right! When I do \encoding BIG5, it works.
> But it seems  that "\encoding" can only be issued in
> psql's command prompt or be done with
> PQsetClientEncoding() in libpq.

Yes.

> If our application for input is written in PHP (4.0.2)
> How do we notify PostgreSQL that the frontend encoding
> is 'BIG5' ? (pg_exec("\encoding BIG5") failed.)

I know there are some patches for supporting \encoding in PHP. Do you
want to get them?

> PostgreSQL 7.1 will support automatic code conversion for
> BIG5 to utf-8. Does it means that we do not have to
> announce client encoding as long as the backend is utf-8?

No. You still need to declare that frontend side encoding is BIG5.

> I have also tried to set the environment variable
> PGCLIENTENCODING to 'BIG5'. But when I execute
> psql and then issue \encoding, it shows 'SQL_ASCII' in 7.0.2.
> Is this environment variable useless in 7.0.x and latter?

After checking the souce, I found the capability to recognize the
PGCLIENTENCODING environment variable has been broken since 7.0.
Attached is the patches for 7.0.3. I am going to fix current as well.

----Next_Part(Fri_Nov_17_11:28:53_2000_809)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libpq.patch"

*** postgresql-7.0.3/src/interfaces/libpq/fe-connect.c~	Mon May 22 06:19:53 2000
--- postgresql-7.0.3/src/interfaces/libpq/fe-connect.c	Fri Nov 17 10:37:23 2000
***************
*** 1505,1514 ****
  			{
  				const char *env;
  
- 				/* query server encoding */
  				env = getenv(envname);
  				if (!env || *env == '\0')
  				{
  					if (!PQsendQuery(conn,
  									 "select getdatabaseencoding()"))
  						goto error_return;
--- 1505,1515 ----
  			{
  				const char *env;
  
  				env = getenv(envname);
  				if (!env || *env == '\0')
  				{
+ 					/* query server encoding if PGCLIENTENCODING
+ 					   is not specified */
  					if (!PQsendQuery(conn,
  									 "select getdatabaseencoding()"))
  						goto error_return;
***************
*** 1516,1521 ****
--- 1517,1535 ----
  					conn->setenv_state = SETENV_STATE_ENCODINGS_WAIT;
  					return PGRES_POLLING_READING;
  				}
+ 				else
+ 				{
+ 					/* otherwise set client encoding in pg_conn struct */
+ 					int encoding = pg_char_to_encoding(env);
+ 					if (encoding < 0)
+ 					{
+ 						strcpy(conn->errorMessage.data,
+ 							   "PGCLIENTENCODING has no valid encoding name.\n");
+ 						goto error_return;
+ 					}
+ 					conn->client_encoding = encoding;
+ 				}
+ 					
  			}
  
  		case SETENV_STATE_ENCODINGS_WAIT:

----Next_Part(Fri_Nov_17_11:28:53_2000_809)----