Add to DDL docs

diff --git a/doc/adminguide/faq.sgml b/doc/adminguide/faq.sgml
index e6ddab961e02a3a38d962d7bf839561a73608569..297d87209556fade40dc6c99c4cc0392a80175d1 100644 (file)
--- a/doc/adminguide/faq.sgml
+++ b/doc/adminguide/faq.sgml
@@ -332,6 +332,37 @@ nodes to get rid of the node formerly using the node ID that needs to
 be held by another node.</para> </answer>
 </qandaentry>
 
+<qandaentry id="fqtnfunctions">
+<question><para> I had a DDL script that set the
+<envar>search_path</envar>; this setting remained in place on the
+database connections on subscriber nodes after
+<application>slon</application> propagated the change to subscriber
+nodes.  A stored procedure, running only on subscribers, wound up
+receiving that search path and behaving unexpectedly.</para> 
+
+<para> This was observed in bug #355. </para>
+</question>
+
+<answer><para> <quote>Best practice</quote> for such functions is that
+they should either:
+<itemizedlist>
+<listitem><para> Reference objects using fully qualified names so that <envar>search_path</envar> is not involved, or </para></listitem>
+<listitem><para> Assign the  search path required by the function  as part of the definition of the function.</para></listitem>
+</itemizedlist>
+</para> </answer>
+
+<answer><para> Future versions of &slony1; will run the command
+<command>RESET ALL;</command> after processing DDL, which will run
+<emphasis>after each statement</emphasis> so that the search path will
+be returned to default early.</para>
+
+<para>This will have the effective result of turning <command>set
+search_path</command> into no operation, as the search path will be
+reset to default before the next statement is processed.
+</para></answer>
+
+</qandaentry>
+
 </qandadiv>
 
 <qandadiv id="faqimpossibilities"> <title> &slony1; FAQ: Impossible Things People Try </title>

diff --git a/doc/adminguide/slonik_ref.sgml b/doc/adminguide/slonik_ref.sgml
index e2a03cfdb4b0a2b7f9d66852fdb94053ca37d4d7..db3bd38c4c21af436e9748da7255f01d1187911a 100644 (file)
--- a/doc/adminguide/slonik_ref.sgml
+++ b/doc/adminguide/slonik_ref.sgml
@@ -2824,13 +2824,17 @@ FAILOVER(
       
      </varlistentry>
     </variablelist>
+
+    <para> The contents of the script are split into individual
+    statements which are logged into the table <xref
+    linkend=tablel.sl-log-script>, and are processed individually,
+    followed by the command <command>RESET ALL;</command>.</para>
     
     <para> See also the warnings in &rddlchanges;.</para>
 
     <para> Note that this is a potentially heavily-locking
     operation, which means that it can get stuck behind other database
     activity.</para>
-  
 
     <para> Note that if you need to make reference to the cluster
     name, you can use the token <command>@CLUSTERNAME@</command>; if
@@ -2868,7 +2872,6 @@ EXECUTE SCRIPT (
     similarly altered to remove replication triggers, therefore
     requiring that exclusive locks be taken out on each node, in
     turn. </para>
-
   
 
    </refsect1>