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
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 |