48.12. pg_collation
The catalogpg_collation describes the available collations, which are essentially mappings from an SQL name to operating system locale categories. SeeSection 22.2 for more information.
Table 48.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).Postgres Pro generally ignores all collations that do not havecollencoding equal to either the current database's encoding or -1, and creation of new entries with the same name as an entry withcollencoding = -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 thatinitdb 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 thetemplate0 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 fromtemplate0. This would currently have to be done manually.