Entonces, tengo pocos servidores Debian con PostgreSQL. Históricamente, esos servidores y PostgreSQL están localizados con el juego de caracteres latino 9 y en aquel entonces estaba bien. Ahora tenemos que manejar cosas como el polaco, el griego o el chino, por lo que cambiarlo se convierte en un problema creciente.
Cuando intenté crear una base de datos UTF8, recibí el mensaje:
ERROR: la codificación UTF8 no coincide con la configuración regional fr_FR Detalle: la configuración LC_CTYPE elegida requiere la codificación LATIN9.
Pocas veces hice una investigación sobre el tema con mi viejo amigo Google, y todo lo que pude encontrar fueron algunos procedimientos demasiado complicados como actualizar Debian LANG
, recompilar PostgreSQL con el juego de caracteres correcto, editar todas las LC_
variables del sistema y otras soluciones oscuras. Entonces, por el momento, dejamos de lado este problema.
Recientemente, volvió de nuevo, los griegos quieren las cosas y Latin 9 no quieren. Y mientras estaba investigando este problema nuevamente, un colega se me acercó y me dijo: "No, es fácil, mira".
No editó nada, no hizo trucos de magia, solo hizo esta consulta SQL:
CREATE DATABASE my_utf8_db
WITH ENCODING='UTF8'
OWNER=admin
TEMPLATE=template0
LC_COLLATE='C'
LC_CTYPE='C'
CONNECTION LIMIT=-1
TABLESPACE=pg_default;
Y funcionó bien.
En realidad no lo sabía LC_CTYPE='C'
y me sorprendió que usar esto no estuviera en las primeras soluciones en Google e incluso en Stack Overflow. Miré a mi alrededor y solo encontré una mención en la documentación de PostgreSQL.
Cuando LC_CTYPE es C o POSIX, se permite cualquier conjunto de caracteres, pero para otras configuraciones de LC_CTYPE solo hay un conjunto de caracteres que funcionará correctamente. Dado que initdb congela la configuración LC_CTYPE, la aparente flexibilidad para usar diferentes codificaciones en diferentes bases de datos de un clúster es más teórica que real, excepto cuando selecciona la configuración regional C o POSIX (deshabilitando así cualquier reconocimiento de la ubicación real).
Entonces me hizo preguntarme, esto es demasiado fácil, demasiado perfecto, ¿cuáles son las desventajas? Y aún me cuesta encontrar una respuesta. Así que aquí vengo publicando aquí:
tl; dr: ¿Cuáles son las desventajas de usar LC_CTYPE='C'
sobre una localización específica? ¿Es malo hacerlo? ¿Qué debería esperar romper?
fuente
collate "C"
después deorder by
. Depende de usted determinar si su aplicación la necesita y dónde. A la mayoría de las aplicaciones no les importa.COLLATE
especificador que difiere de la base de datos.En referencia a la respuesta aceptada de Daniel sobre la ordenación mediante intercalaciones, tenga en cuenta que si está ejecutando PostgreSQL en una Mac, es posible que su intercalación preferida no funcione como esperaba debido a la configuración inadecuada de algunas intercalaciones a nivel del sistema operativo. Puede leer más sobre el tema aquí:
http://www.postgresql.org/message-id/[email protected]
Este no es un problema específico de PostgreSQL, específicamente, sino un problema con la configuración predeterminada de Mac para la configuración de intercalación. Mi sistema actual ejecuta PostgreSQL 9.3 en OS X El Capitan Versión 10.11 y sufre este problema. Mi sistema devuelve los mismos resultados de la consulta, independientemente de si uso la intercalación "fr_FR" o "en_US". Por ejemplo:
Usando la intercalación "fr_FR":
Usando la clasificación "en_US":
En mi sistema, la configuración de intercalación (en el nivel del sistema operativo) es la misma para "fr_FR" y "en_US" como se demuestra en el shell ejecutando diff:
Esperemos que esta información adicional sea útil para cualquiera que lea esto y esté usando PostgreSQL en una Mac que sufre este problema.
fuente