Create an explicit concept of collations that work for any encoding.

Use collencoding = -1 to represent such a collation in pg_collation.
We need this to make the "default" entry work sanely, and a later
patch will fix the C/POSIX entries to be represented this way instead
of duplicating them across all encodings.  All lookup operations now
search first for an entry that's database-encoding-specific, and then
for the same name with collencoding = -1.

Also some incidental code cleanup in collationcmds.c and pg_collation.c.

1 files changed, 7 insertions, 5 deletions

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 297ad532080..64d1cda8990 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -2132,7 +2132,8 @@
       <entry><structfield>collencoding</structfield></entry>
       <entry><type>int4</type></entry>
       <entry></entry>
-      <entry>Encoding to which the collation is applicable</entry>
+      <entry>Encoding in which the collation is applicable, or -1 if it
+       works for any encoding</entry>
      </row>
 
      <row>
@@ -2157,12 +2158,13 @@
    <structfield>collencoding</>, <structfield>collnamespace</>) not just
    (<structfield>collname</>, <structfield>collnamespace</>).
    <productname>PostgreSQL</productname> generally ignores all
-   collations not belonging to the current database's encoding; therefore
-   it is sufficient to use a qualified SQL name
+   collations that do not have <structfield>collencoding</> equal to
+   either the current database's encoding or -1, and creation of new
+   entries matching 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 current database's encoding is automatically used as an additional
-   lookup key.  The reason for defining the catalog this way is that
+   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.