web-dev-qa-db-fra.com

Pourquoi mon PostgreSQL ORDER BY est-il insensible à la casse?

J'ai Postgres 9.4.4 fonctionnant sur Debian et j'obtiens le ORDER BY comportement:

veure_test=# show LC_COLLATE;
 lc_collate  
-------------
 en_US.UTF-8
(1 row)

veure_test=# SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') ORDER BY 1;
 regexp_split_to_table 
-----------------------
 a
 A
 b
 c
 Capacitor
 CD
 d
 D
(8 rows)

Et uname -a:

Linux ---- 3.2.0-4-AMD64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux

Cependant, sur mon iMac, avec Postgres 9.3.4, j'obtiens ce qui suit:

veure_test=# show LC_COLLATE;
 lc_collate  
-------------
 en_US.UTF-8
(1 row)

veure_test=# SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') ORDER BY 1;
 regexp_split_to_table 
-----------------------
 A
 CD
 Capacitor
 D
 a
 b
 c
 d
(8 rows)

Et le uname -a:

Darwin ---- 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64

Je ne comprends pas pourquoi la version Debian semble être insensible à la casse et la version OS X ne l'est pas. Que me manque-t-il ou quelles autres informations dois-je fournir?

Mise à jour: Sur mon Mac, le pg_collation le tableau montre que j'ai un en_US.UTF-8 collation, mais sur Debian, j'ai un en_US.utf8 collation. Ainsi, sur mon Mac:

veure_test=# with foo as (
SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') as bar
   )
SELECT bar FROM foo
ORDER BY bar collate "en_US.UTF-8";                                                                                                                                                                                      
    bar    
-----------
 A
 CD
 Capacitor
 D
 a
 b
 c
 d
(8 rows)

Et sur Debian:

veure_test=# with foo as (
SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') as bar
   )
SELECT bar FROM foo
ORDER BY bar collate "en_US.utf8";
    bar    
-----------
 a
 A
 b
 c
 Capacitor
 CD
 d
 D
(8 rows)

Donc en_US.UTF-8 et en_US.utf8 avez des ordres de tri différents?

postgresqlcollation
29
Curtis Poe

Ainsi, en_US.UTF-8 Et en_US.utf8 Ont des ordres de tri différents?

Non, ces deux sont les mêmes, juste une convention de dénomination différente.

Je ne comprends pas pourquoi la version Debian semble être insensible à la casse et la version OS X ne l'est pas.

Oui tu as raison. Il s'agit du comportement par défaut sur Mac. Les classements ne fonctionnent sur aucun système d'exploitation BSD (y compris OSX) pour l'encodage UTF8.

Voici une référence pour prouver que:

Problèmes avec l'ordre de tri (les locales UTF8 ne fonctionnent pas

Comme a_horse_with_no_name l'a dit, Postgres utilise l'implémentation de classement du système d'exploitation. Il n'y a aucun moyen d'obtenir le même résultat sur les deux systèmes d'exploitation.

Dans votre cas, vous pouvez (j'ai dit peut-être) faire ceci: ORDER BY lower(fieldname).

19
JSapkota