Remove the custom_variable_classes parameter.

This variable provides only marginal error-prevention capability (since
it can only check the prefix of a qualified GUC name), and the consensus
is that that isn't worth the amount of hassle that maintaining the setting
creates for DBAs.  So, let's just remove it.

With this commit, the system will silently accept a value for any qualified
GUC name at all, whether it has anything to do with any known extension or
not.  (Unqualified names still have to match known built-in settings,
though; and you will get a WARNING at extension load time if there's an
unrecognized setting with that extension's prefix.)

There's still some discussion ongoing about whether to tighten that up and
if so how; but if we do come up with a solution, it's not likely to look
anything like custom_variable_classes.

doc/src/sgml/auth-delay.sgml

@@ -42,16 +42,14 @@
   </variablelist>
 
   <para>
-   In order to set these parameters in your <filename>postgresql.conf</> file,
-   you will need to add <literal>auth_delay</> to
-   <xref linkend="guc-custom-variable-classes">.  Typical usage might be:
+   These parameters must be set in <filename>postgresql.conf</>.
+   Typical usage might be:
   </para>
 
 <programlisting>
 # postgresql.conf
 shared_preload_libraries = 'auth_delay'
 
-custom_variable_classes = 'auth_delay'
 auth_delay.milliseconds = '500'
 </programlisting>
  </sect2>

doc/src/sgml/auto-explain.sgml

@@ -158,16 +158,14 @@ LOAD 'auto_explain';
   </variablelist>
 
   <para>
-   In order to set these parameters in your <filename>postgresql.conf</> file,
-   you will need to add <literal>auto_explain</> to
-   <xref linkend="guc-custom-variable-classes">.  Typical usage might be:
+   These parameters must be set in <filename>postgresql.conf</>.
+   Typical usage might be:
   </para>
 
 <programlisting>
 # postgresql.conf
 shared_preload_libraries = 'auto_explain'
 
-custom_variable_classes = 'auto_explain'
 auto_explain.log_min_duration = '3s'
 </programlisting>
  </sect2>

doc/src/sgml/config.sgml

@@ -5940,58 +5940,25 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
     <para>
      This feature was designed to allow parameters not normally known to
      <productname>PostgreSQL</productname> to be added by add-on modules
-     (such as procedural languages).  This allows add-on modules to be
+     (such as procedural languages).  This allows extension modules to be
      configured in the standard ways.
     </para>
 
-    <variablelist>
-
-     <varlistentry id="guc-custom-variable-classes" xreflabel="custom_variable_classes">
-      <term><varname>custom_variable_classes</varname> (<type>string</type>)</term>
-      <indexterm>
-       <primary><varname>custom_variable_classes</> configuration parameter</primary>
-      </indexterm>
-      <listitem>
-       <para>
-        This variable specifies one or several class names to be used for
-        custom variables, in the form of a comma-separated list. A custom
-        variable is a variable not normally known
-        to <productname>PostgreSQL</productname> proper but used by some
-        add-on module.  Such variables must have names consisting of a class
-        name, a dot, and a variable name.  <varname>custom_variable_classes</>
-        specifies all the class names in use in a particular installation.
-        This parameter can only be set in the <filename>postgresql.conf</>
-        file or on the server command line.
-       </para>
-
-      </listitem>
-     </varlistentry>
-    </variablelist>
-
     <para>
-     The difficulty with setting custom variables in
-     <filename>postgresql.conf</> is that the file must be read before add-on
-     modules have been loaded, and so custom variables would ordinarily be
-     rejected as unknown.  When <varname>custom_variable_classes</> is set,
-     the server will accept definitions of arbitrary variables within each
-     specified class.  These variables will be treated as placeholders and
-     will have no function until the module that defines them is loaded. When a
-     module for a specific class is loaded, it will add the proper variable
-     definitions for its class name, convert any placeholder
-     values according to those definitions, and issue warnings for any
-     unrecognized placeholders of its class that remain.
+     Custom options have two-part names: an extension name, then a dot, then
+     the parameter name proper, much like qualified names in SQL.  An example
+     is <literal>plpgsql.variable_conflict</>.
     </para>
 
     <para>
-     Here is an example of what <filename>postgresql.conf</> might contain
-     when using custom variables:
-
-<programlisting>
-custom_variable_classes = 'plpgsql,plperl'
-plpgsql.variable_conflict = use_variable
-plperl.use_strict = true
-plruby.use_strict = true        # generates error: unknown class name
-</programlisting>
+     Because custom options may need to be set in processes that have not
+     loaded the relevant extension module, <productname>PostgreSQL</>
+     will accept a setting for any two-part parameter name.  Such variables
+     are treated as placeholders and have no function until the module that
+     defines them is loaded. When an extension module is loaded, it will add
+     its variable definitions, convert any placeholder values according to
+     those definitions, and issue warnings for any unrecognized placeholders
+     that begin with its extension name.
     </para>
    </sect1>
 

doc/src/sgml/pgstatstatements.sgml

@@ -275,16 +275,13 @@
   </para>
 
   <para>
-   In order to set any of these parameters in your
-   <filename>postgresql.conf</> file,
-   you will need to add <literal>pg_stat_statements</> to
-   <xref linkend="guc-custom-variable-classes">.  Typical usage might be:
+   These parameters must be set in <filename>postgresql.conf</>.
+   Typical usage might be:
 
 <programlisting>
 # postgresql.conf
 shared_preload_libraries = 'pg_stat_statements'
 
-custom_variable_classes = 'pg_stat_statements'
 pg_stat_statements.max = 10000
 pg_stat_statements.track = all
 </programlisting>

doc/src/sgml/plperl.sgml

@@ -1219,10 +1219,6 @@ CREATE TRIGGER test_valid_id_trig
 
   <para>
   This section lists configuration parameters that affect <application>PL/Perl</>.
-  To set any of these parameters before <application>PL/Perl</> has been loaded,
-  it is necessary to have added <quote><literal>plperl</></> to the
-  <xref linkend="guc-custom-variable-classes"> list in
-  <filename>postgresql.conf</filename>.
   </para>
 
   <variablelist>

doc/src/sgml/plpgsql.sgml

@@ -4007,11 +4007,8 @@ BEGIN
     <literal>use_column</> (where <literal>error</> is the factory default).
     This parameter affects subsequent compilations
     of statements in <application>PL/pgSQL</> functions, but not statements
-    already compiled in the current session.  To set the parameter before
-    <application>PL/pgSQL</> has been loaded, it is necessary to have added
-    <quote><literal>plpgsql</></> to the <xref
-    linkend="guc-custom-variable-classes"> list in
-    <filename>postgresql.conf</filename>.  Because changing this setting
+    already compiled in the current session.
+    Because changing this setting
     can cause unexpected changes in the behavior of <application>PL/pgSQL</>
     functions, it can only be changed by a superuser.
    </para>