Change standard_compliant_strings to standard_conforming_strings.

This commit is contained in:
Peter Eisentraut 2005-08-14 22:19:50 +00:00
parent 8ae0d476a9
commit bf86bacb2c
5 changed files with 18 additions and 18 deletions

View File

@ -1,5 +1,5 @@
<!--
$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

View File

@ -1,4 +1,4 @@
<!-- $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</>,

View File

@ -1,5 +1,5 @@
<!--
$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>

View File

@ -1,5 +1,5 @@
<!--
$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

View File

@ -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
},