今回はPostgreSQLの文字コードとロケールに関して記載します。
文字コード
PostgreSQLでは日本語をサポートしている以下の文字コードが利用可能なので、参考にいただければと思います。
ちなみに、サーバ、クライアント共に、設定することが可能なのですが、文字コードが異なる場合、変換が暗黙的に行われるためパフォーマンスに影響するといわれています。サーバと、クライアントの文字コードは合わせることが推奨となります。
| 文字コード名 | 内容 |
|---|---|
| EUC_JP | 日本語拡張Unixコード |
| EUC_JIS_2004 | 日本語拡張Unixコードの一種 |
| SJIS | Shift JISコード。主にWindows系OSで使用される文字コード。 |
| SHIFT_JIS_2004 | Shift JISコードの一種 |
| UTF-8 | UTF8 Unicodeで定義された文字列を表現するコード |
ロケール
ロケールとは地域（国）によって異なる表記や比較規則の設定を行う設定値です。具体的には、単位、記号、日付、通貨などに適用される規則となります。
ロケール設定のメリット
ロケールを設定するメリットを以下に記します。
- 文字列関数で半角英数字と全角英数字を等価に扱えるようになる。（厳密に区別したい場合は適さない）
- 文字列に対してORDER BYを指定した場合、バイトコード順ではなくロケール辞書による並び替えを行える。
- 通貨型を参照した場合、ロケールに従った通貨記号が付与される。
ロケール設定のデメリット
ロケール設定するとメリットだけではなく、デメリットも存在します。ロケール設定のデメリットに関して記載します。
- 並び替え、インデックス作成処理にてロケール処理によるオーバーヘッドが発生。
- 前方一致検索（LIKE ‘条件%’)でインデックスが利用されなくなる。
- OSのロケールに依存するため、OSのバージョンやライブラリバージョンが異なると挙動がかわる。
- ロケールを指定することで指定できる文字コードが固定される可能性がある。（UTF-8以外の文字コードでロケールを利用することは推奨されない）
ロケールの設定をどうしたらいいのか？
Oracle DatabaseからAzure for PostgreSQLの移行を考えたときに、ロケールの設定に関してあまりメリットを感じることが出来なかったため、ロケールは設定しない（locale=C）事が望ましいと考えます。
最後に
文字コードとロケールに関して記載しましたが、ご参考にいただければと思います。
次回は
OracleからPostgreSQLの機能的な違いに関して紹介していきたいと思います。機能的な違いを把握することは、OarcleからAzure Database for PostgreSQLへの移行を考えるうえで重要な事のように思います。