From 637028afe17b9616d279d13d9fc5d6df1ecf369b Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 11 May 2006 19:15:36 +0000
Subject: Code review for standard_conforming_strings patch.  Fix it so it does
 not throw warnings for 100%-SQL-standard constructs, clean up some minor
 infelicities, try to un-break ecpg to the best of my ability.  (It's not
 clear how ecpg is going to find out the setting of
 standard_conforming_strings, though.)  I think pg_dump still needs work, too.

---
 doc/src/sgml/config.sgml | 59 ++++++++++++++++++++++++++++--------------------
 1 file changed, 34 insertions(+), 25 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 933ca3811dc..a2e6d46ca6a 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.57 2006/05/02 18:07:51 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.58 2006/05/11 19:15:35 tgl Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -3734,32 +3734,15 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
        <para>
         When on, a warning is issued if a backslash (<literal>\</>)
         appears in an ordinary string literal (<literal>'...'</>
-        syntax). The default is <literal>on</>.
+        syntax) and <varname>standard_conforming_strings</varname> is off.
+        The default is <literal>on</>.
        </para>
        <para>
-        Escape string syntax (<literal>E'...'</>) should be used for
-        backslash escape sequences, because ordinary strings have
-        the standard-conforming behavior of treating backslashes
-        literally when the <literal>standard-conforming-strings</>
-        option is set <literal>on</>.
-       </para>
-      </listitem>
-     </varlistentry>
-
-     <varlistentry id="guc-standard-conforming-strings" xreflabel="standard_conforming_strings">
-      <term><varname>standard_conforming_strings</varname> (<type>boolean</type>)</term>
-      <indexterm><primary>strings</><secondary>standard conforming</></>
-      <indexterm>
-       <primary><varname>standard_conforming_strings</> configuration parameter</primary>
-      </indexterm>
-      <listitem>
-       <para>
-        Controls whether ordinary string literals
-        (<literal>'...'</>) treat backslashes literally, as specified in
-        the SQL standard.  Applications may check this
-        parameter to determine how string literals will be processed.
-        The presence of this parameter can also be taken as an indication
-        that the escape string syntax (<literal>E'...'</>) is supported.
+        Applications that wish to use backslash as escape should be
+        modified to use escape string syntax (<literal>E'...'</>),
+        because the default behavior of ordinary strings will change
+        in a future release for SQL compatibility.  This variable can
+        be enabled to help detect applications that will break.
        </para>
       </listitem>
      </varlistentry>
@@ -3799,6 +3782,32 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
       </listitem>
      </varlistentry>
 
+     <varlistentry id="guc-standard-conforming-strings" xreflabel="standard_conforming_strings">
+      <term><varname>standard_conforming_strings</varname> (<type>boolean</type>)</term>
+      <indexterm><primary>strings</><secondary>standard conforming</></>
+      <indexterm>
+       <primary><varname>standard_conforming_strings</> configuration parameter</primary>
+      </indexterm>
+      <listitem>
+       <para>
+        This controls whether ordinary string literals
+        (<literal>'...'</>) treat backslashes literally, as specified in
+        the SQL standard.
+        The default is currently <literal>off</>, causing
+        <productname>PostgreSQL</productname> to have its historical
+        behavior of treating backslashes as escape characters.
+        The default will change to <literal>on</> in a future release
+        to improve compatibility with the standard.
+        Applications may check this
+        parameter to determine how string literals will be processed.
+        The presence of this parameter can also be taken as an indication
+        that the escape string syntax (<literal>E'...'</>) is supported.
+        Escape string syntax should be used if an application desires
+        backslashes to be treated as escape characters.
+       </para>
+      </listitem>
+     </varlistentry>
+
      </variablelist>
     </sect2>
 
-- 
cgit v1.2.3