PostgreSQL 7.0 multi-byte (MB) support README	       2000/3/22 作成

							石井達夫
						ishii@postgresql.org
		  http://www.sra.co.jp/people/t-ishii/PostgreSQL/

■はじめに

  PostgreSQL におけるマルチバイトサポートは以下のような特徴を持っています。

    1. マルチバイト文字として、日本語、中国語などの各国の EUC、Unicode、
       mule internal code, ISO-8859-* がデータベース作成時に選択可能。
       データベースにはこのコードのまま格納されます。
    2. テーブル名にマルチバイト文字が使用可能(ただし、OS がマルチバイト
       のファイル名を許していることが必要)
    3. カラム名にマルチバイト文字が使用可能
    4. データそのものにもマルチバイト文字が使用可能
    5. マルチバイト文字の正規表現検索が使用可能
    6. マルチバイト文字の LIKE 検索が使用可能
    7. character_length(), position(), substring() でのマルチバイト
       サポート
    8. フロントエンド側のエンコーディングがバックエンド側と異る場合に、
       自動的にコード変換を行ないます。

■インストール

  デフォルトのコンフィギュレーションでは PostgreSQL はマルチバイトを
  サポートしていません。マルチバイトサポートを有効にする方法を説明します。

  たとえば日本語 EUC を主に利用する場合は、configure 起動時に以下のよ
  うに指定します。

  % ./configure --enable-multibyte=EUC_JP

  エンコーディングとしては EUC_JP の他、以下が指定できます。

	SQL_ASCII	ASCII
	EUC_JP		日本語 EUC
	EUC_CN		GB をベースにした中文EUC。code set 2 は
			SS2+2バイトコード = 3バイト表現です。
	EUC_KR		韓国語 EUC。
	EUC_TW		台湾の EUC。code set 2 は
			SS2+面番号+2バイトコード = 4バイト表現です。
	UNICODE		UTF-8。ただしサポートするのは UCS-2 の範囲、
			すなわち 0xffff までです。
	MULE_INTERNAL	mule の内部コード。ただし、Type N の不定長文字は
			サポートしていません。
	LATIN*		ISO8859 Latin シリーズ。* は 1 から 5 まで指定
			できます。
	キリル文字	KOI8(KOI8-R), WIN(CP1251), ALT(CP866)をサポート
			しています。もちろん ISO 8859-5 も使用可能です。
			この場合、"LATIN5" として指定して下さい。

  選択の目安としては、英語と日本語しか使わない場合は EUC_JP(同様に、中
  国語しか使わない場合は EUC_CN... などとなります)、その他の言語も使いた
  い場合は UNICODE もしくは MULE_INTERNAL となるでしょう。

  エンコーディングを省略した場合、デフォルト値として SQL_ASCII が採用
  されます。

  なお、configure で選択したエンコーディングは、あくまで initdb のための
  デフォルト値程度の意味しかありません(initdb では引数でエンコーディングが
  指定できます)。したがって、異なるエンコーディングを使用するために
  わざわざ PostgreSQL をリコンパイルする必要ありません。

  initdb は shell script なので、デフォルトのエンコーディングは script を
  適当なエディタで編集することにより簡単に変更できます。initdb の 42行目
  付近に、

  MULTIBYTE=EUC_JP

  のような行があるので、= 以降を希望するエンコーディングに変えるだけです。

  注意：MULE_INTERNAL を選ぶと、たくさんの文字集合に対応できて便利です
  が、正規表現で複数の文字集合にまたがるような範囲指定(たとえば、[a-範]
  とか、[abc範囲]のような)は使えません。複数の範囲指定で異なる文字集合
  を使うのは構いません(たとえば [abc][範-囲])。また、[^a] のような表現
  は、"a" の属する文字集合(この場合、US-ASCII)において "a" 以外である
  ことを表します。決して漢字や平仮名など "a" 以外をすべて表すわけでは
  ないことに注意して下さい。

  インストールは --enable-multibye なしの場合と同様に行ないます。イン
  ストールの詳細は INSTALL というテキストファイルを御覧下さい。また、
  http://www.sra.co.jp/people/t-ishii/PostgreSQL/ でも簡単なインストー
  ル方法を紹介しています。

■initdb/createdb/create database におけるエンコーディングの指定について

  initdb では以下のオプションでエンコーディングが指定できます。

	-E エンコーディング
	--encoding=エンコーディング

  ここで指定したエンコーディングは、以後 createdb/create database でエ
  ンコーディングを省略した場合に設定されるエンコーディングになります。
  -E または --encoding オプションを省略した場合は、configure で指定し
  たエンコーディングが採用されます。

  createdb では以下のオプションでエンコーディングが指定できます。

	-E エンコーディング
	--encoding=エンコーディング

  create database では以下のオプションでエンコーディングが指定できます。

	CREATE DATABASE dbanme WITH ENCODING = 'エンコーディング';

  LOCATION を同時に指定する場合は以下のようになります。

	CREATE DATABASE dbanme WITH LOCATION = 'path' ENCODING = 'エンコーディング';

  createdb/create database では、エンコーディング指定を省略した場合は、initdb 
  で指定したエンコーディングが採用されます。これは、initdb が作成する
  テンプレートデータベース(template1)の encoding アトリビュートを継承
  するからです。

  データベースのエンコーディングは、psql -l、psql の \l で参照できます。

$ psql -l
            List of databases
   Database    |  Owner  |   Encoding    
---------------+---------+---------------
 euc_cn        | t-ishii | EUC_CN
 euc_jp        | t-ishii | EUC_JP
 euc_kr        | t-ishii | EUC_KR
 euc_tw        | t-ishii | EUC_TW
 mule_internal | t-ishii | MULE_INTERNAL
 regression    | t-ishii | SQL_ASCII
 template1     | t-ishii | EUC_JP
 test          | t-ishii | EUC_JP
 unicode       | t-ishii | UNICODE
(9 rows)

■フロントエンドとバックエンドの自動エンコーディング変換について

  バックエンド(データベース)と psql などのフロントエンドのエンコーディ
  ングは一致しているのが原則ですが、いくつかのエンコーディングについて
  はバックエンドとフロントエンドの間で異なるものを使用することができま
  す。この場合、自動的にバックエンドでエンコーディング変換が行われます。

  バックエンドのエンコーディング	許容されるフロントエンドの
					エンコーディング
  ----------------------------------------------------------------
	EUC_JP				EUC_JP, SJIS
  
	EUC_TW				EUC_TW, BIG5
  
  	LATIN2				LATIN2, WIN1250
  
	LATIN5				LATIN5, WIN, ALT
  
	MULE_INTERNAL			EUC_JP, SJIS, EUC_KR, EUC_CN, 
					EUC_TW, BIG5, LATIN1から5, 
					WIN, ALT, WIN1250

  バックエンドとフロントエンドのエンコーディングが異なる場合、そのこと
  をバックエンドに伝える必要があります。そのための方法がいくつかありま
  す。

o psql の \encoding コマンドを使う方法

  psqlでは、\encodingコマンドを使って動的にフロントエンド側の文字コー
  ドを切替えることができます。例:

	\encoding SJIS

o libpq の関数 PQsetClientEncoding を使う方法

  7.0 から新しい libpq 関数 PQsetClientEncoding が追加されています。

  PQsetClientEncoding(PGconn *conn, const char *encoding)

  この関数を使えば、コネクション毎にエンコーディングを切替えることがで
  きます。現在のエンコーディングの問い合わせは

  int PQclientEncoding(const PGconn *conn)

  です。

o 環境変数 PGCLIENTENCODING を使う方法

  上記方法で対応できない場合、あるいはフロントエンドで使われるエンコー
  ディングがあらかじめ分かっている場合は環境変数 PGCLIENTENCODING を使
  うのが便利です。この方法は更に大きく2つに分かれます。

  (1) postmaster 起動時に環境変数を設定する方法

  すべてのクライアント(フロントエンド)が同じエンコーディングを使うのが
  分かっている場合、postmaster 起動時に環境変数 PGCLIENTENCODING を設
  定します。この場合でも、(2)の方法で個々のクライアント毎に別のエンコー
  ディングを設定することができます。

  (2) クライアント、フロントエンド毎にエンコーディングを設定したい場合

  この場合はそのフロントエンド(たとえば psql)を起動する前に環境変数 
  PGCLIENTENCODING を設定します。

o set client_encoding コマンドを使う方法

  上記(2)の方法は、libpq を使っていない JDBC や ODBC では使用できませ
  ん。この場合、SQLコマンドである set client_encoding コマンドを利用し
  ます。例：

	set client_encoding to 'sjis';

■現在設定されているフロントエンド側のエンコーディングを調べる

 現在設定されているフロントエンド側のエンコーディングは

	show client_encoding;

  で参照できます。

■デフォルトのエンコーディングへの復帰

  SQLコマンド:

	reset client_encoding;

  は、デフォルトのフロントエンドエンコーディング設定に復帰させます。
  postmasterを立ち上げるときに環境変数 PGCLIENTENCODING が設定されてい
  るとそのエンコーディングに、そうでなければデータベースのエンコーディ
  ングと同じになります。
  
■エンコーディング変換不能の場合の処理

  バックエンド側のエンコーディングとフロントエンド側のエンコーディング
  がいつも相互変換できるとは限りません。極端な話、バックエンド側が 
  EUC_JP なのに、フロントエンド側が EUC_KR だったらどうなるでしょう。
  この場合 PostgreSQL は変換できないコードを 16進表現に変換します。
  たとえば、"(bdae)" のように。なお、この 16進表現は mule
  internal code のコードであることに注意して下さい。これは、直接フロン
  トエンド <--> バックエンドのエンコーディングを変換するのではなく、一
  度内部表現である mule internal code を経由しているためです。

■SJISユーザ定義文字への対応

  7.0 から SJISユーザ定義文字 (UDC) に対応しています。UDC をどう扱うか
  と言うことについて中条さん(nak@email.com)から問題提起と詳細な解説を
  頂きましたので、参考のためにこのドキュメントの最後に付けておきます。
  また、この問題については、PostgreSQL日本語メーリングリストの 
  [pgsql-jp 12288] (1999/12/17付)と [pgsql-jp 12486] (2000/1/5付) から
  始まるスレッドで議論を見ることができます(メールのアーカイブは
  http://www.sra.co.jp/people/t-ishii/PostgreSQL/ で参照できます)。

  ここでは、それらの議論をふまえ、簡単に解説します。

  PostgreSQLでは、日本語を使用する際にバックエンド側のエンコーディング
  を EUC_JP または MULE_INTERNAL or Unicode にする必要があります。
  MULE_INTERNAL は EUC_JP に文字集合を表すコードを付けたものなので、本
  質的に同じです。また、Unicode <---> SJIS 変換は現在のところサポート
  されていませんので無視します。したがって、ここでは EUC_JP と SJIS の
  相互変換のみを考えます。

  予備知識

  一口に EUC_JP といっても、実際には中身は複数の文字集合から成り立って
  います。

	G0: JIS ROMAN (ASCII とほぼ同じ)
	G1: JIS X 0208 (JIS 漢字)
	G2: JIS X 0201 (1バイトカナ)
	G3: JIS X 0212 (JIS 補助漢字)

  一方 SJIS はこのうち基本的に G0, G1, G2 をサポートしており、G3 はサ
  ポートしていません。したがって、SJIS は EUC_JP の部分集合とみなすこ
  とができ、実際 PostgreSQL 6.5 まではこの考えで実装されていました。

  ところが、Windows PC の SJIS の世界では、上記 JIS 規格で定義されてい
  ない文字コードが一部利用されており、この部分 (UDC) は従来 PostgreSQL 
  では全く考慮されていませんでした。実際 UDC を含む SJIS を EUC_JP に
  変換するときに不正な変換が行われていました。そこで PostgreSQL 7.0 で
  は、まずこの問題を解決することにしました。

  また、UDC の利用方については標準規格のようなものはありませんが、実は
  業界団体での取り決めがあり、いわゆるデファクトスタンダードならば存在
  することが分かりました。そこでこれについてもできるだけサポートするこ
  とにしました。

  PostgreSQL 7.0 での UDC 対応の実装

  (1) ユーザ定義文字領域は JIS のユーザ定義文字領域にマッピングする。
  SJIS と EUC_JP で1対1の対応になります。

    - SJIS ユーザ定義文字領域 A (仮称)
          95〜104 区  ←→ 日本語 EUC / G1 (JIS X 0208) 85〜95 区

    - SJIS ユーザ定義文字領域 B (仮称)
         105〜114 区  ←→ 日本語 EUC / G3 (JIS X 0212) 85〜95 区

  (2) IBM 拡張文字領域 (SJIS 115〜120 区)

  変換テーブルによって G1 (JIS X 0208)と、G3 (JIS X 0212)に変換されま
  す。なお、この変換においては、SJIS --> EUC_JP で変換し、再び EUC_JP --
  > SJIS に変換すると元の SJIS に戻らないことがあります。また、EUC_JP --
  > SJIS の変換では、すべての文字を変換できるわけではないので、その場
  合は変換不能文字として「〓」に置き換えます。

  *業界団体の取り決めでは、変換不能文字は「実装依存」となっていますが、
  Solaris をはじめ、多くのシステムが「〓」を変換不能文字に採用していま
  す。PostgreSQLもこれに合わせました。

  (3) NEC 選定 IBM 拡張文字領域 (SJIS 89〜92 区)
  
  PostgreSQL 7.0ではすべて変換不能文字「〓」に置き換えられます。

謝辞：

  o 各種文字セット、コード系について、日本語 PostgreSQL メーリングリスト
    のメンバの方からアドバイスを頂きました。ここに感謝します。
    また、SJIS 対応については、市川@お茶大さんのパッチを参考にさせてい
    ただきました。

  o SJISユーザ定義文字 (UDC) をどう扱うかと言うことについて中条さん
    (nak@email.com)から問題提起と詳細な解説を頂きました。

参考1：

  Pavel Behal氏により提供されたWIN1250サポートですが、Windows環境での
  利用の仕方について参考になるドキュメントが付属しているので、ここに添
  付しておきます。

  -------------------------------------------------------------------
Version: 0.91 for PgSQL 6.5
Author: Pavel Behal
Revised by: Tatsuo Ishii
Email: behal@opf.slu.cz
Licence: The Same as PostgreSQL

Sorry for my Eglish and C code, I'm not native :-)

!!!!!!!!!!!!!!!!!!!!!!!!! NO WARRANTY !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Instalation:
------------
1) Change three affected files in source directories 
    (I don't have time to create proper patch diffs, I don't know how)
	[PostgreSQL 6.5.1ではこのステップは必要ありません。-- 石井]
2) Compile with enabled locale and multibyte set to LATIN2
3) Setup properly your instalation, do not forget to create locale
   variables in your profile (environment). Ex. (may not be exactly true):
	LC_ALL=cs_CZ.ISO8859-2
	LC_COLLATE=cs_CZ.ISO8859-2
	LC_CTYPE=cs_CZ.ISO8859-2
	LC_MONETARY=cs_CZ.ISO8859-2
	LC_NUMERIC=cs_CZ.ISO8859-2
	LC_TIME=cs_CZ.ISO8859-2
4) You have to start the postmaster with locales set!
5) Try it with Czech language, it have to sort
5) Install ODBC driver for PgSQL into your M$ Windows
6) Setup properly your data source. Include this line in your ODBC
   configuration dialog in field "Connect Settings:" :
	SET CLIENT_ENCODING = 'WIN1250';
7) Now try it again, but in Windows with ODBC.

Description:
------------
- Depends on proper system locales, tested with RH6.0 and Slackware 3.6,
  with cs_CZ.iso8859-2 loacle
- Never try to set-up server multibyte database encoding to WIN1250,
  always use LATIN2 instead. There is not WIN1250 locale in Unix
- WIN1250 encoding is useable only for M$W ODBC clients. The characters are
  on thy fly re-coded, to be displayed and stored back properly
 
Important:
----------
- it reorders your sort order depending on your LC_... setting, so don't be
  confused with regression tests, they don't use locale
- "ch" is corectly sorted only in some newer locales (Ex. RH6.0)
- you have to insert money as '162,50' (with comma in aphostrophes!)
- not tested properly
  -------------------------------------------------------------------

参考2：SJISユーザ定義文字 (UDC) をどう扱うかと言うことについて中条さん
    (nak@email.com)からいただいた問題提起と解説です。

-------------------------- 引用開始 ----------------------------------
---
1. SJIS コードの範囲

    1 バイト目 0x81 - 0x9F、0xE0 - 0xFC
    2 バイト目 0x40 - 0x7E、0x80 - 0xFC

    いわゆる「外字領域」の範囲:

    - X0208 共通自由領域

    |--------------------
    | 85 区  0xEB40 〜
    |...
    |--------------------
    | 89 区  0xED40 〜    ; 89〜92 区は
    |...                  ; 「NEC 選定 IBM 拡張文字領域」
    |-------------------- ; と呼ばれる
    | 93 区  0xEF40 〜
    | 94 区  0xEF9F 〜 0xEFFC

    - ユーザ定義文字領域
    
    |--------------------
    | 95 区  0xF040 〜    ; 95〜104 区
    |...                  ; 「ユーザ定義文字領域 A」(仮称)
    |--------------------
    |105 区  0xF540 〜    ; 105〜114 区
    |...                  ; 「ユーザ定義文字領域 B」(仮称)
    |--------------------
    |115 区  0xFA40 〜    ; 115〜120 区は一般に
    |...                  ; 「IBM 拡張文字領域」
    |120 区  ...          ; と呼ばれる
    |--------------------

---
2. i-mode 端末が使っている図形文字コードの範囲

    0xF89F - 0xF8FC  (112 区)
    0xF940 - 0xF949  (113 区)
    0xF972 - 0xF97E  (113 区)
    0xF980 - 0xF990  (113 区)
    0xF9B0           (114 区)

---
3. 一般的な EUC 日本語コードの定義

    G0 : [0x21-0x7E]                  ; いわゆる JIS ROMAN
    G1 : [0xA1-0xFE] [0xA1-0xFE]      ; JIS X 0208 
    G2 : 0x8E [0xA1-0xDF]             ; JIS X 0201 カナ
    G3 : 0x8F [0xA1-0xFE] [0x21-0x7E] ; JIS X 0212 補助漢字

---
[問題点]

SJIS 95〜120 区は JIS X0208 に該当する領域が存在しない
ため、この領域の EUC - SJIS 文字コード変換は各ベンダに
よって異なるのではないか、というのが石井様からのご指摘
でした。

---
[議論]

調査の結果、SJIS 95〜120 区を EUC に変換するための標準的な
ルールがないわけではない、ということがわかりました。詳細は
後述の参考資料をご覧いただくとして、ここではそのルールを
簡単にご説明いたします。

   - SJIS ユーザ定義文字領域 A (仮称)
          95〜104 区  ←→ 日本語 EUC / G1 85〜95 区

         たとえば SJIS の (95, 1) = 0xF040 は
         EUC の 0xF5A1 になります。

   - SJIS ユーザ定義文字領域 B (仮称)
         105〜114 区  ←→ 日本語 EUC / G3 85〜95 区

         たとえば SJIS の (105, 1) = 0xF540 は
         EUC の 0x8FF5A1 になります。

   - IBM 拡張文字領域
         115〜120 区

         JIS X 0208 (日本語 EUC / G1)、JIS X 0212 
         (日本語 EUC / G3) に該当する文字がある場合
         はその文字にマッピング。そうでない場合は
         日本語 EUC / G3 83〜84 区を、区点コードの上位
         から順に割り当てていく (変換テーブル方式)

この仕様は、広く使われている SJIS と EUC のマッピングがベンダに
よって異なるため、相互運用の際に問題になっていることから、1996 
年に OSF 日本ベンダ協議会が検討作成した報告書がベースになってい
るようです。

Solaris のドキュメントには「TOG 日本ベンダ協議会推奨 EUC・シフト 
JIS コード変換仕様」にもとづくと書いてあり、Solaris 2.6 から導入
しているのだそうで、私から見れば事実上の標準と考えても不自然では
ないと感じます。

なお、少なくとも 1996 年当時においては、Oracle や Sybase は 
SJIS のユーザ定義/ベンダ定義文字領域を EUC に変換する際、判別不
可能文字として扱っているらしいということも補足しておきます。

---
[参考資料]

// URL が長いので、途中で切れないといいのですが...

-「日本語 EUC・シフト JIS コード変換仕様とコード系実態調査」
    1966, OSF 日本ベンダ協議会
    http://www.opengroup.or.jp/jvc/cde/sjis-euc.html

-「文字コード変換規則」
    Solaris 7、JFP ユーザーズガイド
    http://docs.sun.com/ab2/coll.139.3/JFPUG/@Ab2PageView/11683?Ab2Lang=ja&Ab2Enc=euc-jp

-「日本語文字コード」
    Solaris 7、JFP ユーザーズガイド
    http://docs.sun.com/ab2/coll.139.3/JFPUG/@Ab2PageView/879;td=5?Ab2Lang=ja&Ab2Enc=euc-jp

    // 謎の「1〜20 区」の記述はここからきています。

---
-------------------------- 引用ここまで ---------------------------------

改定履歴：

  2000/3/22
	* PQsetClientEncoding, PQclientEncoding をlibpq 関数に追加、
	  コネクション毎にエンコーディングを変更可能に。
	* SJIS ユーザ定義文字 (UDC) への対応
  	* ./configure --with-mb=EUC_JP から
	  ./configure --enable-multibyte=EUC_JP に変更
  	* SQL_ASCII の regression test 追加
	* これらは 7.0 に反映されます。

  1999/7/11 WIN1250(Windows用のチェコ語)サポートを追加しました。
	* WIN1250 がフロントエンド側のエンコーディングとして利用できるよ
	  うになりました。この場合、バックエンド側のエンコーディングは
	  LATIN2 または MULE_INTERNAL とします。
	  (contributed by Pavel Behal)
	* backend/utils/mb/conv.cにおける型の不整合を修正しました。
	  (contributed by Tomoaki Nishiyama)
	* これらは6.5.1に反映されます。

  1999/3/23 キリル文字サポート追加他(6.5 に反映済)
	* エンコーディングとして KOI8(KOI8-R), WIN(CP1251), ALT(CP866) を
	  サポートしています。これらは、フロントエンド、バックエンド、
	  どちらのエンコーディングとしても使用可能であり、エンコーディングの
	  相互変換が可能です。また、従来からサポートしている ISO 8859-5 も
	  同様に使用可能です。
	  キリル文字サポートは、Oleg Broytmann <phd@sun.med.ru> 氏の
	  リクエスト及び協力により実現しました。これは、従来からある
	  RCODE サポートの機能を取り込むものでもあります。
	* MB と locale を同時に指定した場合に大文字／小文字を無視した
	  正規表現検索が正常に動作しないバグを修正

  1999/1/26 Big5 サポート追加(6.4.2-patched/6.5 に反映済)
	* Big5 がフロントエンド側のエンコーディングとして利用できるよ
	  うになりました。この場合、バックエンド側のエンコーディングは
	  EUC_TW または MULE_INTERNAL とします。
	* EUC_TW の regression test ケースを追加
	  (contributed by Jonah Kuo <jonahkuo@mail.ttn.com.tw>)

  1998/12/16 本ドキュメント修正(6.4.2 に反映済)。
	* Makefile.custom で MB=EUC_JP などと設定する方法は 6.4 以降
	  サポートされていないので削除した。
	* 文字コード → エンコーディング、クライアント→フロントエンド
	  サーバ→バックエンド にそれぞれ語句を修正。

  1998/12/15 6.4 向けバグ修正パッチリリース(6.4.2 に反映済)。
	* SQL_ASCII サポートのバグ修正

  1998/11/21 6.4 向けバグ修正パッチリリース(6.4.2 に反映済)。
	* BINARY CURSOR の問題を修正
	* pg_dumpall のバグ修正

  1998/11/5 6.4 リリース。
	* pg_database の encoding カラムが MB が有効でないときにも
	  追加されるようになった。そのため、MB が有効でないときには、
	  ASCII のエンコーディングを表す SQL_ASCII を新しいエンコーディング
	  として追加した。これにともない、エンコーディング名に対応する
	  エンコーディングIDが SQL_ASCII を 0 とする番号に変更になった。

  1998/7/22 6.4 α向けにパッチをリリース。
	* initdb/createdb/create database でバックエンド側の
	  エンコーディングを設定きる機能実装。このため、システムカタロ
	  グの pg_database に新しいカラム encoding を追加(MBが有効な時だけ)
	* copy が PGCLIENTENCODING に対応
	* SQL92 の "SET NAMES" をサポート(MBが有効な時だけ)
	* LATIN2-5 をサポート
	* regression test に unicode のテストケースを追加
	* MB 専用の regression テストディレクトリ test/mb を追加
	* ソースファイルの置き場所を大幅見直し。MB 関係は
	  include/mb, backend/utils/mb に置くようにした

  1998/5/25 バグ修正(mb_b3.patch として pgsql-jp ML にリリース、
	本家では 6.4 snapshot に取り込まれる予定)	

  1998/5/18 機能追加／バグ修正(mb_b2.patch として pgsql-jp ML にリリース、
	本家では 6.4 snapshot に取り込まれる予定)
	* 環境変数 PGCLIENTENCODING のサポート。フロントエンド側の
	  エンコーディングを指定する。現在、SJIS, EUC_*, MULE_INTERNAL, 
	  LATIN1 が指定できる。また、
	  set client_encoding to 'sjis';
	  でも可能
	* 8bit 文字が渡ると問題が起きる箇所にできるだけ対応

  1998/4/21 機能追加／バグ修正(mb_b1.patch として pgsql-jp ML にリリース、
	本家では 6.4 snapshot に取り込まれている)
	* character_length(), position(), substring() のマルチバイト
	  対応
	* octet_length() 追加 → initdb のやり直し必要
	* configure のオプションに MB サポート追加
	  (ex. configure --with-mb=EUC_JP)
	* EUC_KR の regression test 追加
	  ("Soonmyung. Hong" <hong@lunaris.hanmesoft.co.kr> さん提供)
	* EUC_JP の regression test に character_length(), position(),
	  substring(), octet_length() 追加
	* regress.sh の SystemV における非互換性修正
	* toupper(), tolower() に 8bit 文字が渡ると落ちることが
	  あるのを修正

  1998/3/25 PostgreSQL 6.3.1 リリース、MB PL2 が取り込まれる

  1998/3/10 PL2 をリリース
	* EUC_JP, EUC_CN, MULE_INTERNAL の regression test を追加
	  (EUC_CN のデータは he@sra.co.jp さん提供)
	* regexp において、isalpha などに unsigend char 以外の値が
          渡らないようにガードをかける
	* 英語のドキュメントを追加
	* MB を定義しない場合に発生するバグを修正

  1998/3/1 PL1 をリリース

以上。
