[pgsql-jp: 25269] Re: Unicode マッピングの問題

[Tatsuo Ishii]

石井です．

> 加澤です。

> 上記ページでも、[pgsql-jp 21134] にも徳家さんが書かれていますが、
> このパッチを本家に merge できない、という点は非常にもどかしいです
> ね。backend が Unicode の場合、EUC_JP 系クライアントと SJIS 系
> クライアントを混在させるためには、双方 JIS 系のマッピングを使うか、
> 双方 CP932 系のマッピングを使うしかないはずで、現在 Shift JIS コ
> ンバータとして CP932 系しか選択できないとすると、上記パッチは本来
> 必須なはずです。
> 
> ライセンスやポリシーの問題でどうしても不可能だ、というのであれば、
> Shift JIS コンバータに JIS 系のものを追加する、という解決策はとれ
> ないのでしょうか？つまり Java と同じ方法論です。
> 
> Java の方法を絶対視しているわけではありませんが、RDBMS のように
> 雑多なプラットフォームから利用される可能性のあるシステムの場合にも、
> コンバータを多数用意しユーザーの選択に任せる、という方法論は Good
> だと思うんですが…。

私としては，マッピング表をUnicodeの規定するものから掛け離れたものにす
るのは抵抗があります．本来マッピング表も含めてUnicodeの規格のはずです
から．

ですが，マッピング(コンバータ)を複数用意するのには賛成です．ただ，現在
のアーキテクチャでこれをやろうとすると，むやみにPostgreSQLのロードモ
ジュールがでかくなってしまうのが難点です(ロードモジュールがでかくなっ
ても性能には関係ないからいいという意見もあるようですが)．

根本的にこの問題を解決するためには，動的にコンバージョンテーブルを定義
できるようにすればいいのですが，そのためにはCREATE CHARACTER SETなどを
実装する必要があります．ただ，7.3に間に合わせることを考えるとフル実装
は難しいと思います．とりあえず列やテーブル単位で文字集合を定義できるの
はあきらめて，今まで通りデータベース単位での文字集合定義でもいいかな，
と弱気になっています:-)7.3では，SCHEMAの実装も考えられているようなので，
どうなるかわかりませんが...

ただ，7.3ではアーカイブログからのリカバリとか，他にもやりたいことがあ
るのでどうしようかと悩んでいるところです．
--
Tatsuo Ishii