Re: [INTERFACES] JDBC and character sets

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
Cc: "'Herouth Maoz'" <herouth(at)oumail(dot)openu(dot)ac(dot)il>, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] JDBC and character sets
Date: 1999-06-23 01:31:17
Message-ID: 199906230131.KAA01670@ext16.sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

> 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

Browse pgsql-interfaces by date

  From Date Subject
Next Message Daren Sefcik 1999-06-23 01:37:40 Solaris + ColdFusion + PostgreSQL + ODBC
Previous Message Steffen Zimmert 1999-06-22 23:05:06 Arrays in PostgreSQL