Neden PostgreSQL ORDER BY büyük / küçük harfe duyarsız?

Debian'da çalışan Postgres 9.4.4'üm var ve şu ORDER BYdavranışları alıyorum :

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)

Ve uname -a:

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

Ancak, iMac'imde Postgres 9.3.4 ile aşağıdakileri alıyorum:

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)

Ve 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

Debian sürümünün neden büyük / küçük harfe duyarsız göründüğü ve OS X sürümünün neden olmadığı konusunda şaşırdım. Neyi kaçırdım ya da başka hangi bilgileri vermem gerekiyor?

Güncelleme : Mac'imde, pg_collationtabloda bir en_US.UTF-8harmanlama var, ancak Debian'da bir en_US.utf8harmanlama var. Böylece, Mac'imde:

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)

Ve Debian'da:

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)

Peki en_US.UTF-8ve en_US.utf8farklı sıralama düzenleri var?

postgresql collation

— Curtis Poe
kaynak

Test edeceğim bir Mac'im yok, bu yüzden burada karanlıkta çekim yapıyorum ... İpin Mac'te 'D d a A c b CD Capacitor'bir textalan olarak kullanılmaması ihtimali var mı? IE, SELECT regexp_split_to_table('D d a A c b CD Capacitor'::text, ' ') ORDER BY 1;ne olduğunu görmeye çalış ...

— Chris

Aynı sonuç. Öte yandan, OS X’in select * from pg_collationdediği gibi Debian’ın kutusunun olduğunu gösteriyor . Açıkça ilgili kutulardaki harmanlamayı zorlamak için bunları kullanmak, farklı sıralama düzenlerini gösterir :(en_US.utf8en_US.UTF-8

— Curtis Poe

Ve sorunu açıklayabilecek bir güncelleme yayınladım, ama benim için sadece gizemi derinleştiriyor. Ve şimdi bunu buldum: stackoverflow.com/questions/19967555/… ve bu: stackoverflow.com/questions/27395317/…

— Curtis Poe

Maalesef Postgres, işletim sistemini bu tür davranışları işletim sistemine bağımlı kılan (kişisel olarak bir hata olduğunu düşündüğüm - bir DBMS'nin işletim sistemi ne olursa olsun aynı olması gerekir) kullanan işletim sistemi harmanlama uygulamasını kullanır. Böylece bu, Debian ve OSX arasındaki sistem kütüphanelerinde farklılıklara yol

— açar

Sıralama düzeni diğerlerine uymuyorsa Postgres ile sistemin diğer kısımları arasında anlaşmazlık olacaktır. Ben de aynı davranışı tercih ediyorum, ancak sistemin yerel ayarını izlemesi için ona hata demem. Sonuçta, aynı yerel yerler OS'de aynı şekilde davranmalıdır. Debian yerel sağa görünüyor (başka bir açıklaması olmadığı sürece), Elma hatalı gibi görünüyor.

— Erwin Brandstetter

Peki en_US.UTF-8ve en_US.utf8farklı sıralama düzenleri var?

Hayır, ikisi de aynı, sadece farklı bir adlandırma kuralı.

Debian sürümünün neden büyük / küçük harfe duyarsız göründüğü ve OS X sürümünün neden olmadığı konusunda şaşırdım.

Evet haklısın. Mac'teki varsayılan davranış budur. Harmanlamalar, UTF8kodlama için herhangi bir BSD ish OS'de (OSX dahil) çalışmaz .

İşte bunu kanıtlamak için bir referans:

Sıralama düzeniyle ilgili sorunlar (UTF8 yerel ayarları çalışmıyor)

Gibi a_horse_with_no_name söyledi Postgrees OS harmanlama uygulaması kullanır. Her iki işletim sisteminde de aynı sonucu elde etmenin bir yolu yoktur.

Durumda da olabilir böyle yapmak (Belki dedim): ORDER BY lower(fieldname).

— JSapkota
kaynak

ORDER BY function()Potansiyel olarak büyük sonuçlarda kullanırken performansı doğrulamaya özen gösterin - sıralama için bir endeksin kullanılmasını durdurduğundan, neredeyse kesinlikle fazladan bir sıralama işlemine (muhtemelen diskte) neden olur ve sorgu planlayıcısının sorgunuza daha geniş bir şekilde saldırma yöntemini değiştirebilir .

— David Spillett

@David Spillett: Sipariş işlevi konusunda haklısın. Cevabımın OP'nin neden iMac ve Debian'da farklı sıralama tarzlarına sahip olduğuna odaklandığını düşünüyorum. Teşekkürler

— JSapkota

Evet, cevabınız tamamen iyi ve soruyu tamamen kapsıyor. "Sorgu planını etkileyebilecek değişikliklerden sonra gerçek verilerle test etme" denilince, unutmak kolay olduğu için (ve çoğu zaman herkesin yaptığı gibi) unutulmayacak kadar zorlayıcı bir tepki haline geldi. Veritabanı çalışması için yeni insanlar için bile bilmiyorum.

— David Spillett