Received: from ext16.sra.co.jp (IDENT:root@ykh28DS17.kng.mesh.ad.jp [133.205.214.17]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA29900 for ; Tue, 22 Jun 1999 21:36:43 -0400 (EDT) (envelope-from t-ishii@ext04.sra.co.jp) Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1]) by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA01670; Wed, 23 Jun 1999 10:31:17 +0900 Message-Id: <199906230131.KAA01670@ext16.sra.co.jp> To: Peter Mount cc: "'Herouth Maoz'" , pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] JDBC and character sets From: Tatsuo Ishii Reply-To: t-ishii@sra.co.jp In-reply-to: Your message of Tue, 22 Jun 1999 16:55:43 +0100. <1B3D5E532D18D311861A00600865478C9FCB@exchange1.nt.maidstone.gov.uk> Date: Wed, 23 Jun 1999 10:31:17 +0900 Sender: t-ishii@ext04.sra.co.jp > That's my main worry, and one of the reasons I haven't really looked at > it yet. > > What we would need is some way for the client to see if the backend was > compiled for unicode, and enable that functionality if it is, or default > to ASCII if not. You could issue "select getdatabaseencoding()" to judge for that. 1) if that fails, the backend is not compiled with MB support. 2) if it returns other than "UNICODE", the backend is compiled with MB but the encoding for the database is not Unicode. (Note that in MB, the encoding for a database can be decided at its creation time. So it may not always be UNICODE even if you comiled with --with-mb=UNICODE). Possible encoding returned by the function would be: SQL_ASCII ASCII EUC_JP Japanese EUC EUC_CN Chinese EUC EUC_KR Korean EUC EUC_TW Taiwan EUC UNICODE Unicode(UTF-8) MULE_INTERNAL Mule internal LATIN1 ISO 8859-1 English and some European languages LATIN2 ISO 8859-2 English and some European languages LATIN3 ISO 8859-3 English and some European languages LATIN4 ISO 8859-4 English and some European languages LATIN5 ISO 8859-5 English and some European languages KOI8 KOI8-R WIN CP1251 ALT CP866 See doc/README.mb for more details. --- Tatsuo Ishii