selectステートメントでcollat​​eを使用するPostgreSQL9.1

あなたのデザインに欠陥は見つかりません。試しました。

ロケールと照合

私はこの質問を再検討しました。このsqlfiddleのテストケースについて考えてみましょう。 。それはうまく機能しているようです。ロケールca_ES.utf8も作成しました ローカルテストサーバー（DebianSqueeze上のPostgreSQL9.1.6）で、ロケールをDBクラスターに追加しました：

CREATE COLLATION "ca_ES" (LOCALE = 'ca_ES.utf8');

上記のsqlfiddleで見られるのと同じ結果が得られます。

照合名は識別子であり、"ca_ES"のようなキャメルケースのスペルを保持するために二重引用符で囲む必要があることに注意してください 。システム内の他のロケールとの混乱があったのではないでしょうか。 利用可能な照合 を確認してください ：

SELECT * FROM pg_collation;

通常、照合ルールはシステムロケールから派生します。 。 詳細についてはこちらのマニュアルをご覧ください 。それでも間違った結果が得られる場合は、システムを更新して、"ca_ES"のロケールを再生成しようとします。 。 Debian（および関連するLinuxディストリビューション）では、これは次の方法で実行できます。

dpkg-reconfigure locales

NFC

もう1つのアイデアがあります：正規化されていないUNICODE文字列 。

あなたの'Àudio'かもしれません 実際には'̀ ' || 'Audio' ？それがこのキャラクターになります：

SELECT U&'\0300A';
SELECT ascii(U&'\0300A');
SELECT chr(768);

ウィキペディアのアキュートアクセント の詳細を読む 。
SET standard_conforming_strings = TRUEする必要があります 最初の行のようにUnicode文字列を使用します。

一部のブラウザは正規化されていないUnicode文字を正しく表示できず、多くのフォントには特殊文字の適切なグリフがないため、ここに何も表示されないか、ぎこちないことがあります。しかし、UNICODEはそのナンセンスを考慮に入れています。何が得られたかをテストして確認します：

SELECT octet_length('̀A')  -- returns 3 (!)
SELECT octet_length('À')  -- returns 2

それがあなたのデータベースが契約したものであるならば、あなたはそれを取り除くか、結果に苦しむ必要があります。解決策は、文字列をNFC に正規化することです。 。 Perlには優れたUNICODE-fooスキルがあり、plperlu関数でライブラリを利用してPostgreSQLで実行できます。私は狂気から私を救うためにそれをしました。

DavidWheelerによるPostgreSQLでのUNICODE正規化 。
unicode.orgのUnicode正規化フォーム に関する厄介な詳細をすべて読んでください。 。