>From 2ab86c1cd230b4187ee994447075bd6a72b408dc Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Sat, 14 Sep 2013 23:15:10 +0200
Subject: [PATCH] Allow custom GUCs to be nested more than one level in config
 files

Doing so was allowed via SET, postgres -c and set_config()
before. Allowing to do so is useful for grouping together variables
inside an extension's toplevel namespace.

There still are differences in the accepted variable names between the
different methods of setting GUCs after this commit, but the concensus
is that those are acceptable.
---
 doc/src/sgml/config.sgml          | 29 ++++++++++++++++++++---------
 src/backend/utils/misc/guc-file.l |  2 +-
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 370aa09..ae9ef3b 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -6375,21 +6375,32 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
     </para>
 
     <para>
-     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</>.
+     Custom options consist out of an extension name, then a dot, zero
+     or more extension internal namespaces each with a trailing dot,
+     then the parameter name proper, much like qualified names in
+     SQL. An example without extension internal namespaces
+     is <literal>plpgsql.variable_conflict</>, one with
+     is <literal>foo.a.connection</>.
     </para>
 
     <para>
      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.
+     will accept a setting for any parameter name containing at least one dot.
+     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>
+
+    <para>
+     Note that options set in <filename>postgresql.conf</> and files
+     it includes have different restrictions than names set
+     with <command>SET</>, <command>SELECT set_config(...)</>, or ones
+     passed directly to <command>postgres</> and <command>pg_ctl</>.
+    </para>
+
    </sect1>
 
    <sect1 id="runtime-config-developer">
diff --git a/src/backend/utils/misc/guc-file.l b/src/backend/utils/misc/guc-file.l
index b730a12..ff4202d 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -78,7 +78,7 @@ LETTER			[A-Za-z_\200-\377]
 LETTER_OR_DIGIT [A-Za-z_0-9\200-\377]
 
 ID				{LETTER}{LETTER_OR_DIGIT}*
-QUALIFIED_ID	{ID}"."{ID}
+QUALIFIED_ID	{ID}("."{ID})+
 
 UNQUOTED_STRING {LETTER}({LETTER_OR_DIGIT}|[-._:/])*
 STRING			\'([^'\\\n]|\\.|\'\')*\'
-- 
1.8.4.21.g992c386.dirty