doc_collation_conversion_order.patch
text/x-patch
Filename: doc_collation_conversion_order.patch
Type: text/x-patch
Part: 1
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: unified
| File | + | − |
|---|---|---|
| doc/src/sgml/catalogs.sgml | 114 | 114 |
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 @@ </table> </sect1> + <sect1 id="catalog-pg-collation"> + <title><structname>pg_collation</structname></title> + + <indexterm zone="catalog-pg-collation"> + <primary>pg_collation</primary> + </indexterm> + + <para> + The catalog <structname>pg_collation</structname> describes the + available collations, which are essentially mappings from an SQL + name to operating system locale categories. + See <xref linkend="collation"> for more information. + </para> + + <table> + <title><structname>pg_collation</> Columns</title> + + <tgroup cols="1"> + <thead> + <row> + <entry>Has OID column</entry> + </row> + </thead> + <tbody> + <row> + <entry>Yes</entry> + </row> + </tbody> + </tgroup> + + <tgroup cols="4"> + <thead> + <row> + <entry>Name</entry> + <entry>Type</entry> + <entry>References</entry> + <entry>Description</entry> + </row> + </thead> + + <tbody> + <row> + <entry><structfield>collname</structfield></entry> + <entry><type>name</type></entry> + <entry></entry> + <entry>Collation name (unique per namespace and encoding)</entry> + </row> + + <row> + <entry><structfield>collnamespace</structfield></entry> + <entry><type>oid</type></entry> + <entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry> + <entry> + The OID of the namespace that contains this collation + </entry> + </row> + + <row> + <entry><structfield>collowner</structfield></entry> + <entry><type>oid</type></entry> + <entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry> + <entry>Owner of the collation</entry> + </row> + + <row> + <entry><structfield>collencoding</structfield></entry> + <entry><type>int4</type></entry> + <entry></entry> + <entry>Encoding in which the collation is applicable, or -1 if it + works for any encoding</entry> + </row> + + <row> + <entry><structfield>collcollate</structfield></entry> + <entry><type>name</type></entry> + <entry></entry> + <entry><symbol>LC_COLLATE</> for this collation object</entry> + </row> + + <row> + <entry><structfield>collctype</structfield></entry> + <entry><type>name</type></entry> + <entry></entry> + <entry><symbol>LC_CTYPE</> for this collation object</entry> + </row> + </tbody> + </tgroup> + </table> + + <para> + Note that the unique key on this catalog is (<structfield>collname</>, + <structfield>collencoding</>, <structfield>collnamespace</>) not just + (<structfield>collname</>, <structfield>collnamespace</>). + <productname>PostgreSQL</productname> generally ignores all + collations that do not have <structfield>collencoding</> equal to + either the current database's encoding or -1, and creation of new entries + with the same name as an entry with <structfield>collencoding</> = -1 + is forbidden. Therefore it is sufficient to use a qualified SQL name + (<replaceable>schema</>.<replaceable>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 + <application>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. + </para> + + <para> + In the <literal>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 + <literal>template0</>. This would currently have to be done manually. + </para> + </sect1> + <sect1 id="catalog-pg-constraint"> <title><structname>pg_constraint</structname></title> @@ -2377,120 +2491,6 @@ </sect1> - <sect1 id="catalog-pg-collation"> - <title><structname>pg_collation</structname></title> - - <indexterm zone="catalog-pg-collation"> - <primary>pg_collation</primary> - </indexterm> - - <para> - The catalog <structname>pg_collation</structname> describes the - available collations, which are essentially mappings from an SQL - name to operating system locale categories. - See <xref linkend="collation"> for more information. - </para> - - <table> - <title><structname>pg_collation</> Columns</title> - - <tgroup cols="1"> - <thead> - <row> - <entry>Has OID column</entry> - </row> - </thead> - <tbody> - <row> - <entry>Yes</entry> - </row> - </tbody> - </tgroup> - - <tgroup cols="4"> - <thead> - <row> - <entry>Name</entry> - <entry>Type</entry> - <entry>References</entry> - <entry>Description</entry> - </row> - </thead> - - <tbody> - <row> - <entry><structfield>collname</structfield></entry> - <entry><type>name</type></entry> - <entry></entry> - <entry>Collation name (unique per namespace and encoding)</entry> - </row> - - <row> - <entry><structfield>collnamespace</structfield></entry> - <entry><type>oid</type></entry> - <entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry> - <entry> - The OID of the namespace that contains this collation - </entry> - </row> - - <row> - <entry><structfield>collowner</structfield></entry> - <entry><type>oid</type></entry> - <entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry> - <entry>Owner of the collation</entry> - </row> - - <row> - <entry><structfield>collencoding</structfield></entry> - <entry><type>int4</type></entry> - <entry></entry> - <entry>Encoding in which the collation is applicable, or -1 if it - works for any encoding</entry> - </row> - - <row> - <entry><structfield>collcollate</structfield></entry> - <entry><type>name</type></entry> - <entry></entry> - <entry><symbol>LC_COLLATE</> for this collation object</entry> - </row> - - <row> - <entry><structfield>collctype</structfield></entry> - <entry><type>name</type></entry> - <entry></entry> - <entry><symbol>LC_CTYPE</> for this collation object</entry> - </row> - </tbody> - </tgroup> - </table> - - <para> - Note that the unique key on this catalog is (<structfield>collname</>, - <structfield>collencoding</>, <structfield>collnamespace</>) not just - (<structfield>collname</>, <structfield>collnamespace</>). - <productname>PostgreSQL</productname> generally ignores all - collations that do not have <structfield>collencoding</> equal to - either the current database's encoding or -1, and creation of new entries - with the same name as an entry with <structfield>collencoding</> = -1 - is forbidden. Therefore it is sufficient to use a qualified SQL name - (<replaceable>schema</>.<replaceable>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 - <application>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. - </para> - - <para> - In the <literal>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 - <literal>template0</>. This would currently have to be done manually. - </para> - </sect1> - <sect1 id="catalog-pg-conversion"> <title><structname>pg_conversion</structname></title>