Change standard_compliant_strings to standard_conforming_strings.

doc/src/sgml/libpq.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.188 2005/06/27 02:04:24 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.189 2005/08/14 22:19:49 petere Exp $
 -->
 
  <chapter id="libpq">
@@ -890,10 +890,10 @@ Parameters reported as of the current release include
 <literal>DateStyle</>,
 <literal>TimeZone</>,
 <literal>integer_datetimes</>, and
-<literal>standard_compliant_strings</>.
+<literal>standard_conforming_strings</>.
 (<literal>server_encoding</>, <literal>TimeZone</>, and
 <literal>integer_datetimes</> were not reported by releases before 8.0;
-<literal>standard_compliant_strings</> was not reported by releases
+<literal>standard_conforming_strings</> was not reported by releases
 before 8.1.)
 Note that
 <literal>server_version</>,
@@ -917,7 +917,7 @@ in a numeric form that is much easier to compare against.
 </para>
 
 <para>
-If no value for <literal>standard_compliant_strings</> is reported,
+If no value for <literal>standard_conforming_strings</> is reported,
 applications may assume it is <literal>false</>, that is, backslashes
 are treated as escapes in string literals.  Also, the presence of this
 parameter may be taken as an indication that the escape string syntax

doc/src/sgml/protocol.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.61 2005/06/27 02:04:24 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.62 2005/08/14 22:19:49 petere Exp $ -->
 
 <chapter id="protocol">
  <title>Frontend/Backend Protocol</title>
@@ -1061,10 +1061,10 @@
     <literal>DateStyle</>,
     <literal>TimeZone</>,
     <literal>integer_datetimes</>, and
-    <literal>standard_compliant_strings</>.
+    <literal>standard_conforming_strings</>.
     (<literal>server_encoding</>, <literal>TimeZone</>, and
     <literal>integer_datetimes</> were not reported by releases before 8.0;
-    <literal>standard_compliant_strings</> was not reported by releases
+    <literal>standard_conforming_strings</> was not reported by releases
     before 8.1.)
     Note that
     <literal>server_version</>,

doc/src/sgml/runtime.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.344 2005/08/11 21:11:42 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.345 2005/08/14 22:19:49 petere Exp $
 -->
 
 <chapter Id="runtime">
@@ -4089,7 +4089,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
         Escape string syntax (<literal>E'...'</>) should be used for
         escapes, because in future versions of
         <productname>PostgreSQL</productname> ordinary strings will have
-        the standard-compliant behavior of treating backslashes
+        the standard-conforming behavior of treating backslashes
         literally.
        </para>
       </listitem>
@@ -4303,11 +4303,11 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
       </listitem>
      </varlistentry>
 
-     <varlistentry id="guc-standard-compliant-strings" xreflabel="standard_compliant_strings">
-      <term><varname>standard_compliant_strings</varname> (<type>boolean</type>)</term>
+     <varlistentry id="guc-standard-conforming-strings" xreflabel="standard_conforming_strings">
+      <term><varname>standard_conforming_strings</varname> (<type>boolean</type>)</term>
       <indexterm><primary>strings</><secondary>escape</></>
       <indexterm>
-       <primary><varname>standard_compliant_strings</> configuration parameter</primary>
+       <primary><varname>standard_conforming_strings</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>

doc/src/sgml/syntax.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.102 2005/06/26 19:16:05 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.103 2005/08/14 22:19:50 petere Exp $
 -->
 
 <chapter id="sql-syntax">
@@ -274,7 +274,7 @@ UPDATE "my_table" SET "a" = 5;
      While ordinary strings now support C-style backslash escapes,
      future versions will generate warnings for such usage and
      eventually treat backslashes as literal characters to be
-     standard-compliant. The proper way to specify escape processing is
+     standard-conforming. The proper way to specify escape processing is
      to use the escape string syntax to indicate that escape
      processing is desired. Escape string syntax is specified by writing
      the letter <literal>E</literal> (upper or lower case) just before

src/backend/utils/misc/guc.c

@@ -10,7 +10,7 @@
  * Written by Peter Eisentraut <peter_e@gmx.net>.
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.281 2005/08/11 21:11:47 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.282 2005/08/14 22:19:50 petere Exp $
  *
  *--------------------------------------------------------------------
  */
@@ -202,7 +202,7 @@ static int	max_index_keys;
 static int	max_identifier_length;
 static int	block_size;
 static bool	integer_datetimes;
-static bool	standard_compliant_strings;
+static bool	standard_conforming_strings;
 
 /* should be static, but commands/variable.c needs to get at these */
 char	   *role_string;
@@ -930,12 +930,12 @@ static struct config_bool ConfigureNamesBool[] =
 	},
 
 	{
-		{"standard_compliant_strings", PGC_INTERNAL, PRESET_OPTIONS,
+		{"standard_conforming_strings", PGC_INTERNAL, PRESET_OPTIONS,
 			gettext_noop("'...' strings treat backslashes literally."),
 			NULL,
 			GUC_REPORT | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
 		},
-		&standard_compliant_strings,
+		&standard_conforming_strings,
 		false, NULL, NULL
 	},