50.12. pg_collation
В каталоге pg_collation описываются доступные правила сортировки, которые по сути представляют собой сопоставления идентификаторов SQL с категориями локалей операционной системы. За дополнительными сведениями обратитесь к Разделу 23.2.
Таблица 50.12. Столбцы pg_collation
| Имя | Тип | Ссылки | Описание |
|---|---|---|---|
oid | oid | Идентификатор строки (скрытый атрибут; должен выбираться явно) | |
collname | name | Имя правила сортировки (уникальное для пространства имён и кодировки) | |
collnamespace | oid | | OID пространства имён, содержащего это правило сортировки |
collowner | oid | | Владелец правила сортировки |
collencoding | int4 | Кодировка, для которой применимо это правило, или -1, если оно работает с любой кодировкой | |
collcollate | name | LC_COLLATE для данного объекта | |
collctype | name | LC_CTYPE для данного объекта |
Заметьте, что уникальный ключ в этом каталоге определён как (collname, collencoding, collnamespace), а не просто как (collname, collnamespace). Вообще PostgreSQL игнорирует все правила сортировки, для которых collencoding не равняется кодировке текущей базы данных или -1, а создание новых записей с тем же именем, которое уже имеет запись с collencoding = -1, запрещено. Таким образом, достаточно использовать полное имя SQL (схема.имя) для указания правила сортировки, несмотря на то, что оно может быть неуникальным согласно определению каталога. Такая организация каталога объясняется тем, что программа initdb наполняет его в момент инициализации кластера записями для всех локалей, обнаруженных в системе, так что она должна иметь возможность сохранить записи для всех кодировок, которые могут вообще когда-либо применяться в кластере.
В базе данных template0 может быть полезно создать правила сортировки, кодировки которых не соответствуют кодировке этой базы, но которые могут оказаться у баз данных, скопированных впоследствии из template0. В настоящее время это придётся проделать вручную.
50.12. pg_collation
The catalog pg_collation describes the available collations, which are essentially mappings from an SQL name to operating system locale categories. See Section 23.2 for more information.
Table 50.12. pg_collation Columns
| Name | Type | References | Description |
|---|---|---|---|
oid | oid | Row identifier (hidden attribute; must be explicitly selected) | |
collname | name | Collation name (unique per namespace and encoding) | |
collnamespace | oid | | The OID of the namespace that contains this collation |
collowner | oid | | Owner of the collation |
collencoding | int4 | Encoding in which the collation is applicable, or -1 if it works for any encoding | |
collcollate | name | LC_COLLATE for this collation object | |
collctype | name | LC_CTYPE for this collation object |
Note that the unique key on this catalog is (collname, collencoding, collnamespace) not just (collname, collnamespace). PostgreSQL generally ignores all collations that do not have collencoding equal to either the current database's encoding or -1, and creation of new entries with the same name as an entry with collencoding = -1 is forbidden. Therefore it is sufficient to use a qualified SQL name (schema.name) to identify a collation, even though this is not unique according to the catalog definition. The reason for defining the catalog this way is that initdb fills it in at cluster initialization time with entries for all locales available on the system, so it must be able to hold entries for all encodings that might ever be used in the cluster.
In the template0 database, it could be useful to create collations whose encoding does not match the database encoding, since they could match the encodings of databases later cloned from template0. This would currently have to be done manually.