Solve a problem of LC_TIME of windows.

"Hiroshi Saito" <[email protected]> Mon, 15 Sep 2008 22:34:13 +0900
Newsgroups gmane.comp.db.postgresql.devel.patches
Message-ID <03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D>
This is a multi-part message in MIME format.

------=_NextPart_000_03C0_01C91783.2E159210
Content-Type: text/plain;
	format=flowed;
	charset="iso-2022-jp";
	reply-type=original
Content-Transfer-Encoding: 7bit

Hi.

I have problem of LC_TIME of windows.(CVS-HEAD)

As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is expressed.)
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png

As for Version 8.4. It came to be used by Tom-san in strftime of Native-windowsAPI.
It is good improvement.! But, strftime of Native returns a result by CODEPAGE of
environment of operation by Windows with LC_TIME. In Japanese environment, return
value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by SERVER_ENCODING.:-(
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png

Then, I'm proposal patch. It is solved splendidly.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt

Regards,
Hiroshi Saito 

------=_NextPart_000_03C0_01C91783.2E159210
Content-Type: application/octet-stream;
	name="pg_locale_patch-v3"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="pg_locale_patch-v3"

*** src/backend/utils/adt/pg_locale.c.orig	Sat Sep 13 19:13:13 2008=0A=
--- src/backend/utils/adt/pg_locale.c	Sun Sep 14 09:40:46 2008=0A=
***************=0A=
*** 54,59 ****=0A=
--- 54,60 ----=0A=
  #include "utils/memutils.h"=0A=
  #include "utils/pg_locale.h"=0A=
=20=20=0A=
+ #include "mb/pg_wchar.h"=0A=
=20=20=0A=
  #define		MAX_L10N_DATA		80=0A=
=20=20=0A=
***************=0A=
*** 438,443 ****=0A=
--- 439,501 ----=0A=
  	CurrentLocaleConvValid =3D true;=0A=
  	return &CurrentLocaleConv;=0A=
  }=0A=
+=20=0A=
+ #ifdef WIN32=0A=
+ /*=0A=
+  * result is obtained by locale setup of LC_TIME in the environment=20=0A=
+  * of windows at present CP_ACP. Therefore, conversion is needed=0A=
+  * for SERVER_ENCODING. SJIS which is not especially made to server=20=0A=
+  * encoding in Japan returns.=20=0A=
+  */=0A=
+ #define STRLEN_MAX 255=0A=
+ size_t=0A=
+ conv_strftime(char *src, size_t len, const char *format, const struct tm =
*tm)=0A=
+ {=0A=
+ 	char	timesrc[STRLEN_MAX];=0A=
+ 	char	widechar[STRLEN_MAX];=0A=
+ 	char	*convstr;=0A=
+ 	int	dest_encoding;=0A=
+=20=0A=
+ 	strftime(timesrc, len, format, tm);=0A=
+ 	dest_encoding =3D GetDatabaseEncoding();=0A=
+ 	if (dest_encoding =3D=3D PG_SQL_ASCII)=0A=
+ 	{=0A=
+ 		memcpy(src, timesrc, len);=0A=
+ 		src[len] =3D '\0';=0A=
+ 		return len;=0A=
+ 	}=0A=
+=20=0A=
+ 	len =3D MultiByteToWideChar(CP_ACP, 0, timesrc, len,=20=0A=
+ 			(LPWSTR)widechar, STRLEN_MAX);=0A=
+ 	len =3D WideCharToMultiByte(CP_UTF8, 0, (LPWSTR)widechar,=20=0A=
+ 			-1, timesrc, STRLEN_MAX, NULL, NULL);=0A=
+=20=0A=
+ 	timesrc[len] =3D '\0';=0A=
+=20=0A=
+ 	if (dest_encoding =3D=3D PG_UTF8)=0A=
+ 	{=0A=
+ 		convstr =3D pnstrdup(timesrc, len);=0A=
+ 	}=0A=
+ 	else=0A=
+ 	{=0A=
+ 		convstr =3D pg_do_encoding_conversion(timesrc, len, PG_UTF8, dest_encod=
ing);=0A=
+ 		if (convstr =3D=3D NULL)=0A=
+ 		{=0A=
+ 			elog(ERROR, "encoding conversion failed");=0A=
+ 		}=0A=
+ 		len =3D strlen(convstr);=0A=
+         }=0A=
+=20=0A=
+ 	memcpy(src, convstr, len);=0A=
+ 	src[len] =3D '\0';=0A=
+ 	pfree(convstr);=0A=
+=20=0A=
+ 	return len;=0A=
+ }=0A=
+=20=0A=
+ #define strftime(a,b,c,d) conv_strftime(a,b,c,d)=0A=
+=20=0A=
+ #endif /* WIN32 */=0A=
=20=20=0A=
=20=20=0A=
  /*=0A=

------=_NextPart_000_03C0_01C91783.2E159210
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--=20
Sent via pgsql-patches mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

------=_NextPart_000_03C0_01C91783.2E159210--