Move the built-in conversions into the initial catalog data.

Instead of running a SQL script to create the standard conversion
functions and pg_conversion entries, put those entries into the
initial data in postgres.bki.

This shaves a few percent off the runtime of initdb, and also allows
accurate comments to be attached to the conversion functions; the
previous script labeled them with machine-generated comments that
were not quite right for multi-purpose conversion functions.
Also, we can get rid of the duplicative Makefile and MSVC perl
implementations of the generation code for that SQL script.

A functional change is that these pg_proc and pg_conversion entries
are now "pinned" by initdb.  Leaving them unpinned was perhaps a
good thing back while the conversions feature was under development,
but there seems no valid reason for it now.

Also, the conversion functions are now marked as immutable, where
before they were volatile by virtue of lacking any explicit
specification.  That seems like it was just an oversight.

To avoid using magic constants in pg_conversion.dat, extend
genbki.pl to allow encoding names to be converted, much as it
does for language, access method, etc names.

John Naylor

Discussion: https://postgr.es/m/CAJVSVGWtUqxpfAaxS88vEGvi+jKzWZb2EStu5io-UPc4p9rSJg@mail.gmail.com

1 files changed, 7 insertions, 2 deletions

diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml
index def63eb615d..3c5830bc8ad 100644
--- a/doc/src/sgml/bki.sgml
+++ b/doc/src/sgml/bki.sgml
@@ -410,7 +410,7 @@
     catalogs, <filename>genbki.pl</filename> provides mechanisms to write
     symbolic references instead.  Currently this is possible for references
     to access methods, functions, languages,
-    operators, opclasses, opfamilies, and types.
+    operators, opclasses, opfamilies, types, and encodings.
     The rules are as follows:
    </para>
 
@@ -424,11 +424,16 @@
       is <literal>pg_am</literal>, <literal>pg_proc</literal>,
       <literal>pg_language</literal>,
       <literal>pg_operator</literal>, <literal>pg_opclass</literal>,
-      <literal>pg_opfamily</literal>, or <literal>pg_type</literal>.
+      <literal>pg_opfamily</literal>,
+      <literal>pg_type</literal>,
+      or <literal>encoding</literal>.
       <literal>BKI_LOOKUP</literal> can be attached to columns of
       type <type>Oid</type>, <type>regproc</type>, <type>oidvector</type>,
       or <type>Oid[]</type>; in the latter two cases it implies performing a
       lookup on each element of the array.
+      It's also permissible to attach <literal>BKI_LOOKUP</literal>
+      to integer columns; this should be done only for encodings,
+      which are not currently represented as catalog OIDs.
      </para>
     </listitem>