Как сменить язык в postgresql

Как сменить язык в postgresql

Поддержка языковых стандартов в приложениях относится к культурным предпочтениям, которые касаются алфавита, порядка сортировки, форматирования чисел и т. п. PostgreSQL использует соответствующие стандартам ISO C и POSIX возможности локали, предоставляемые операционной системой сервера. За дополнительной информацией обращайтесь к документации вашей системы.

24.1.1. Обзор

Поддержка локали автоматически инициализируется, когда кластер базы данных создаётся при помощи initdb . initdb инициализирует кластер баз данных по умолчанию с локалью из окружения выполнения. Поэтому, если ваша система уже использует локаль, которую вы хотите выбрать для вашего кластера баз данных, вам не требуется дополнительно совершать никаких действий. Если вы хотите использовать другую локаль (или вы точно не знаете, какая локаль используется в вашей системе), вы можете указать для initdb , какую именно локаль использовать, задав параметр —locale . Например:

Данный пример для Unix-систем задаёт русский язык ( ru ), на котором говорят в России ( RU ). Другими вариантами могут быть en_US (американский английский) и fr_CA (канадский французский). Если в языковом окружении может использоваться более одного набора символов, значение может принимать вид language_territory.codeset . Например, fr_BE.UTF-8 обозначает французский язык (fr), на котором говорят в Бельгии (BE), с кодировкой UTF-8 .

То, какие локали и под какими именами доступны на вашей системе, зависит от того, что было включено в операционную систему производителем и что из этого было установлено. В большинстве Unix-систем команда locale -a выведет список доступных локалей. Windows использует более развёрнутые имена локалей, такие как German_Germany или Russian_Russia.1251 , но принципы остаются теми же.

Иногда целесообразно объединить правила из различных локалей, например, использовать английские правила сравнения и испанские сообщения. Для этой цели существует набор категорий локали, каждая из которых управляет только определёнными аспектами правил локализации:

Эти имена категорий initdb принимает в качестве имён соответствующих параметров, позволяющих переопределить выбор локали в определённой категории. Например, чтобы настроить локаль на канадский французский, но при этом использовать американские правила форматирования денежных сумм, используйте initdb —locale=fr_CA —lc-monetary=en_US .

Если вы хотите, чтобы система работала без языковой поддержки, используйте специальное имя локали C либо эквивалентное ему POSIX .

Значения некоторых категорий локали должны быть заданы при создании базы данных. Вы можете использовать различные параметры локали для различных баз данных, но после создания базы вы уже не сможете изменить их для этой базы данных. LC_COLLATE и LC_CTYPE являются этими категориями. Они влияют на порядок сортировки в индексах, поэтому они должны быть зафиксированы, иначе индексы на текстовых столбцах могут повредиться. (Однако можно смягчить эти ограничения через задание правил сравнения, как это описано в разделе Раздел 24.2.) Значения по умолчанию для этих категорий определяются при запуске initdb , и эти значения используются при создании новых баз данных, если другие значения не указаны явно в команде CREATE DATABASE .

Прочие категории локали вы можете изменить в любое время, настроив параметры конфигурации сервера, которые имеют такое же имя как и категории локали (подробнее см. Подраздел 20.11.2). Значения, выбранные через initdb , фактически записываются лишь в файл конфигурации postgresql.conf , чтобы использоваться по умолчанию при запуске сервера. Если вы удалите эти значения из postgresql.conf , сервер получит соответствующие значения из своей среды выполнения.

Обратите внимание на то, что поведение локали сервера определяется переменными среды, установленными на стороне сервера, а не средой клиента. Таким образом, необходимо правильно сконфигурировать локаль перед запуском сервера. Если же клиент и сервер работают с разными локалями, то сообщения, возможно, будут появляться на разных языках в зависимости от того, где они возникают.

Примечание

Когда мы говорим о наследовании локали от среды выполнения, это означает следующее для большинства операционных систем: для определённой категории локали, к примеру, для правил сортировки, следующие переменные среды анализируются в приведённом ниже порядке до тех пор, пока одна из них не окажется заданной: LC_ALL , LC_COLLATE (или переменная, относящаяся к соответствующей категории), LANG . Если ни одна из этих переменных среды не задана, значение локали устанавливается по умолчанию в C .

Некоторые библиотеки локализации сообщений также обращаются к переменной среды LANGUAGE , которая заменяет все прочие параметры локализации при выборе языка сообщений. В случае затруднений, пожалуйста, воспользуйтесь документацией по вашей операционной системе, в частности, справкой по gettext .

24.1.2. Поведение

Локаль влияет на следующий функционал SQL:

Порядок сортировки в запросах с использованием ORDER BY или стандартных операторах сравнения текстовых данных

Функции upper , lower , и initcap

Операторы поиска по шаблону ( LIKE , SIMILAR TO , и регулярные выражения в стиле POSIX); локаль влияет как на поиск без учёта регистра, так и на классификацию знаков по классам символов регулярных выражений

Семейство функций to_char

Недостатком использования отличающихся от C или POSIX локалей в PostgreSQL является влияние на производительность. Это замедляет обработку символов и мешает LIKE использовать обычные индексы. По этой причине используйте локали только в том случае, если они действительно вам нужны.

В качестве обходного решения, которое позволит PostgreSQL пользоваться индексами с предложениями LIKE с использованием локали, отличной от С, существует несколько классов пользовательских операторов. Они позволяют создать индекс, который выполняет строгое посимвольное сравнение, игнорируя правила сравнения, соответствующие локали. За дополнительными сведениями обратитесь к Разделу 11.10. Ещё один подход заключается в создании индексов с помощью правил сортировки C , как было сказано в Разделе 24.2.

24.1.3. Выбор локалей

Локали могут выбираться на разных уровнях в зависимости от требований. В обзоре выше показано, как выбрать локаль при вызове initdb , чтобы на уровне кластера установить для параметров локали значения, которые будут использоваться по умолчанию. В следующем списке показано, где ещё можно выбирать локали. В каждом пункте устанавливаются значения по умолчанию для последующих пунктов, и в каждом последующем пункте можно переопределить заданные выше значения на более низком уровне.

Как объяснялось выше, по умолчанию значения языковых параметров в инициализируемом кластере БД определяются переменными среды ОС. Во многих случаях этого достаточно: если операционная система настроена для нужного языка/региона, то PostgreSQL по умолчанию также будет вести себя в соответствии с этой локалью.

Как показано выше, значения параметров локали для инициализируемого кластера также можно указать в аргументах командой строки initdb . Используйте эту возможность, если вы хотите выбрать для вашей СУБД локаль, отличную от текущей локали операционной системы.

Локаль можно выбрать для отдельной базы данных. Предназначенные для этого параметры имеются у SQL-команды CREATE DATABASE и соответствующей ей внешней команды createdb . Это полезно, например, когда в одном кластере содержатся базы данных, принадлежащие различным клиентам с разными потребностями.

Параметры локали можно задать для отдельных столбцов таблицы. Для этого используются объекты SQL, которые называются правила сортировки и описаны в Разделе 24.2. Это полезно для сортировки данных на разных языках или для изменения порядка сортировки конкретной таблицы.

24.1.4. Провайдеры локалей

PostgreSQL поддерживает различных провайдеров локалей, то есть библиотеки, предоставляющие данные локалей. Стандартный провайдер с именем libc использует системную библиотеку C и предоставляет её локали. Именно эти локали используются большинством утилит операционной системы. Также есть провайдер icu , который использует внешнюю библиотеку ICU . Локали ICU можно использовать, только если поддержка ICU была включена в конфигурации сборки PostgreSQL.

Все команды и утилиты, позволяющие устанавливать параметры локали, как описано выше, позволяют выбрать и провайдера локали. Во всех предыдущих примерах использовался провайдер libc (выбираемый по умолчанию). Выбрать провайдера ICU можно так:

За подробностями обратитесь к описанию соответствующих команд и программ. Обратите внимание, что вы можете использовать различных провайдеров локалей на разных уровнях, например, использовать libc по умолчанию для кластера, но иметь базу данных, использующую провайдера icu , а также иметь в этих базах данных объекты правил сортировки, использующие любых доступных провайдеров.

Рекомендации по выбору провайдера локали зависят от конкретных требований. Для большинства обычных задач подойдёт любой провайдер. Возможности провайдера libc зависят от операционной системы — в одних системах он более функционален, чем в других. Для задач сложных рекомендуется использовать провайдера ICU, так как он предлагает больше вариантов локалей и расширенные возможности.

24.1.5. Проблемы

Если поддержка локализации не работает в соответствии с объяснением, данным выше, проверьте, насколько корректна конфигурация поддержки локализации в вашей операционной системе. Чтобы проверить, какие локали установлены на вашей системе, вы можете использовать команду locale -a , если ваша операционная система поддерживает это.

Проверьте, действительно ли PostgreSQL использует локаль, которую вы подразумеваете. Параметры LC_COLLATE и LC_CTYPE определяются при создании базы данных, и не могут быть изменены, за исключением случаев, когда создаётся новая база данных. Прочие параметры локали, включая LC_MESSAGES и LC_MONETARY первоначально определены средой, в которой запускается сервер, но могут быть оперативно изменены. Вы можете проверить текущие параметры локали с помощью команды SHOW .

Каталог src/test/locale в комплекте файлов исходного кода содержит набор тестов для поддержки локализации PostgreSQL .

Клиентские приложения, которые обрабатывают ошибки сервера, разбирая текст сообщения об ошибке, очевидно, столкнутся с проблемами, когда сообщения сервера будут на другом языке. Авторам таких приложений рекомендуется пользоваться системой кодов ошибок в качестве альтернативы.

Для поддержки наборов переводов сообщений требуется постоянная работа большого числа волонтёров, которые хотят, чтобы в PostgreSQL правильно использовался предпочитаемый ими язык. Если в настоящее время сообщения на вашем языке недоступны или переведены не полностью, будем благодарны вам за содействие. Если вы хотите помочь, обратитесь к Главе 57 или напишите на адрес рассылки разработчиков.

change the UI lang when using postgresql psql.exe

I have a PostgreSQL 8.4 database, installed with Japanese as the main language. I am connecting from an English Windows 7 client using psql.exe. Is there any way to change the UI of the messages shown to me (e.g. the help, column headers from the \l command, etc) to English?

I know that I can set the character encoding using \encoding, but I really want to change the UI language from ja_JP to en_US (or similar).

I can’t see anything in the psql documentation. Any ideas?

2 Answers 2

In Windows also, psql only looks at the LC_MESSAGES environment variable. Therefore this works.

I ran into the same problems. I tried to set locale properly during PostgreSQL installation, tried to change postgresql.conf but nothing helped to change the language in psql. Found out the UI language of psql.exe is controlled by environment variables in Windows. But set LC_MESSAGES=C modifies only current shell variable and it is saved temporarily, so as soon as you close the shell (or restart PC), your issue is back.

These 4 options change the UI language of psql.exe to English and make sure to keep this setting persistently to avoid returning of the issue:

• Option 1: Open Command Prompt and run: setx LC_MESSAGES C . Difference between set and setx is explained here: https://superuser.com/a/916652/1741056
• Option 2: Open Powershell run command: [Environment]::SetEnvironmentVariable("LC_MESSAGES", "C", "User") . See reference here https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables?view=powershell-7.2#saving-environment-variables-with-setenvironmentvariable
• Option 3: In Windows GUI follow this steps: System Properties -> Advanced -> Environment variables -> User variables -> New -> Name: LC_MESSAGES -> Value: C -> OK
• Option 4 (not a pure way! — but is works): Rename this folder C:\Program Files\PostgreSQL\8\share\locale\ja (in case of Japan language and version 8 of PostgreSQL) to something different and restart shell. Here is the reference for this step https://stackoverflow.com/questions/191428/change-language-of-system-and-error-messages-in-postgresql/56811670#comment121662022_56811670

The Overflow Blog

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.3.13.43306

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

PostgreSQL — Кириллица в psql под Windows

В статье пойдёт речь о том, как добиться корректного вывода кириллицы в «консоли» Windows ( cmd.exe ).

Содержание

Описание проблемы

В дистрибутив PostgreSQL, помимо всего прочего, для работы с СУБД входит:

• приложение с графическим интерфейсом pgAdmin ;
• консольная утилита psql .

При работе с psql в среде Windows пользователи всегда довольно часто сталкиваются с проблемой вывода кириллицы. Например, при отображении результатов запроса к таблице, в полях которых хранятся строковые данные на русском языке.

Ну и зачем тогда работать с psql , кому нужно долбить клавиатурой в консольке, когда можно всё сделать красиво и быстро в pgAdmin ? Ну, не всегда pgAdmin доступен, особенно если речь идёт об удалённой машине. Кроме того, выполнение SQL-запросов в текстовом режиме консоли — это +10 к хакирству.

Решение проблемы

• MS Windows 7 SP1 x64;
• PostgreSQL 8.4.12 x32.

На сервере имеется БД, созданная в кодировке UTF8.

Суть проблемы в том, что cmd.exe работает (и так будет до скончания времён) в кодировке CP866 , а сама Windows — в WIN1251 , о чём psql предупреждает при начале работы:

Значит, надо как-то добиться, чтобы кодировка была одна.

В разных источниках встречаются разные рецепты, включая правку реестра и подмену файлов в системных папках Windows. Ничего этого делать не нужно, достаточно всего трёх шагов:

1. сменить шрифт у cmd.exe ;
2. сменить текущую кодовую страницу cmd.exe ;
3. сменить кодировку на стороне клиента в psql .

Конкретные действия

Супер быстро и просто

Запускаете cmd.exe , оттуда psql :

Быстро и просто

Запускаете cmd.exe , оттуда psql :

Вводите пароль (если установлен) и выполняете команду:

И всё. Теперь результаты запроса, содержащие кириллицу, будут отображаться нормально. Но есть небольшой косяк:

Потому предлагаем ещё способ, который этого недостатка лишён.

Посложнее и подольше

Запустить cmd.exe , нажать мышью в правом левом верхнем углу окна, там Свойства — Шрифт — выбрать Lucida Console. Нажать ОК.

В ответ выведет:

Кстати, обратите внимание — теперь предупреждения о несовпадении кодировок нет.

Как сменить язык в postgresql

Locale support refers to an application respecting cultural preferences regarding alphabets, sorting, number formatting, etc. PostgreSQL uses the standard ISO C and POSIX locale facilities provided by the server operating system. For additional information refer to the documentation of your system.

24.1.1. Overview

Locale support is automatically initialized when a database cluster is created using initdb . initdb will initialize the database cluster with the locale setting of its execution environment by default, so if your system is already set to use the locale that you want in your database cluster then there is nothing else you need to do. If you want to use a different locale (or you are not sure which locale your system is set to), you can instruct initdb exactly which locale to use by specifying the —locale option. For example:

This example for Unix systems sets the locale to Swedish ( sv ) as spoken in Sweden ( SE ). Other possibilities might include en_US (U.S. English) and fr_CA (French Canadian). If more than one character set can be used for a locale then the specifications can take the form language_territory.codeset . For example, fr_BE.UTF-8 represents the French language (fr) as spoken in Belgium (BE), with a UTF-8 character set encoding.

What locales are available on your system under what names depends on what was provided by the operating system vendor and what was installed. On most Unix systems, the command locale -a will provide a list of available locales. Windows uses more verbose locale names, such as German_Germany or Swedish_Sweden.1252 , but the principles are the same.

Occasionally it is useful to mix rules from several locales, e.g., use English collation rules but Spanish messages. To support that, a set of locale subcategories exist that control only certain aspects of the localization rules:

The category names translate into names of initdb options to override the locale choice for a specific category. For instance, to set the locale to French Canadian, but use U.S. rules for formatting currency, use initdb —locale=fr_CA —lc-monetary=en_US .

If you want the system to behave as if it had no locale support, use the special locale name C , or equivalently POSIX .

Some locale categories must have their values fixed when the database is created. You can use different settings for different databases, but once a database is created, you cannot change them for that database anymore. LC_COLLATE and LC_CTYPE are these categories. They affect the sort order of indexes, so they must be kept fixed, or indexes on text columns would become corrupt. (But you can alleviate this restriction using collations, as discussed in Section 24.2.) The default values for these categories are determined when initdb is run, and those values are used when new databases are created, unless specified otherwise in the CREATE DATABASE command.

The other locale categories can be changed whenever desired by setting the server configuration parameters that have the same name as the locale categories (see Section 20.11.2 for details). The values that are chosen by initdb are actually only written into the configuration file postgresql.conf to serve as defaults when the server is started. If you remove these assignments from postgresql.conf then the server will inherit the settings from its execution environment.

Note that the locale behavior of the server is determined by the environment variables seen by the server, not by the environment of any client. Therefore, be careful to configure the correct locale settings before starting the server. A consequence of this is that if client and server are set up in different locales, messages might appear in different languages depending on where they originated.

When we speak of inheriting the locale from the execution environment, this means the following on most operating systems: For a given locale category, say the collation, the following environment variables are consulted in this order until one is found to be set: LC_ALL , LC_COLLATE (or the variable corresponding to the respective category), LANG . If none of these environment variables are set then the locale defaults to C .

Some message localization libraries also look at the environment variable LANGUAGE which overrides all other locale settings for the purpose of setting the language of messages. If in doubt, please refer to the documentation of your operating system, in particular the documentation about gettext .