diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 2dfb40f..2b85ba4 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -2087,6 +2087,120 @@ + + <structname>pg_collation</structname> + + + pg_collation + + + + The catalog pg_collation describes the + available collations, which are essentially mappings from an SQL + name to operating system locale categories. + See for more information. + + + + <structname>pg_collation</> Columns + + + + + Has OID column + + + + + Yes + + + + + + + + Name + Type + References + Description + + + + + + collname + name + + Collation name (unique per namespace and encoding) + + + + collnamespace + oid + pg_namespace.oid + + The OID of the namespace that contains this collation + + + + + collowner + oid + pg_authid.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. + + + <structname>pg_constraint</structname> @@ -2377,120 +2491,6 @@ - - <structname>pg_collation</structname> - - - pg_collation - - - - The catalog pg_collation describes the - available collations, which are essentially mappings from an SQL - name to operating system locale categories. - See for more information. - - - - <structname>pg_collation</> Columns - - - - - Has OID column - - - - - Yes - - - - - - - - Name - Type - References - Description - - - - - - collname - name - - Collation name (unique per namespace and encoding) - - - - collnamespace - oid - pg_namespace.oid - - The OID of the namespace that contains this collation - - - - - collowner - oid - pg_authid.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. - - - <structname>pg_conversion</structname>