-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.296 2010/07/16 22:25:47 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.297 2010/07/20 00:34:44 rhaas Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
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 SQL standard.
+ Beginning in <productname>PostgreSQL</productname> 9.1, the default is
+ <literal>on</> (prior releases defaulted to <literal>off</>).
Applications can check this
parameter to determine how string literals will be processed.
The presence of this parameter can also be taken as an indication
-<!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.147 2010/07/03 02:57:46 rhaas Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.148 2010/07/20 00:34:44 rhaas Exp $ -->
<chapter id="sql-syntax">
<title>SQL Syntax</title>
If the configuration parameter
<xref linkend="guc-standard-conforming-strings"> is <literal>off</>,
then <productname>PostgreSQL</productname> recognizes backslash escapes
- in both regular and escape string constants. This is for backward
- compatibility with the historical behavior, where backslash escapes
- were always recognized.
- Although <varname>standard_conforming_strings</> currently defaults to
- <literal>off</>, the default will change to <literal>on</> in a future
- release for improved standards compliance. Applications are therefore
- encouraged to migrate away from using backslash escapes. If you need
- to use a backslash escape to represent a special character, write the
- string constant with an <literal>E</> to be sure it will be handled the same
- way in future releases.
+ in both regular and escape string constants. However, as of
+ <productname>PostgreSQL</> 9.1, the default is <literal>on</>, meaning
+ that backslash escapes are recognized only in escape string constants.
+ This behavior is more standards-compliant, but might break applications
+ which rely on the historical behavior, where backslash escapes
+ were always recognized. As a workaround, you can set this parameter
+ to <literal>off</>, but it is better to migrate away from using backslash
+ escapes. If you need to use a backslash escape to represent a special
+ character, write the string constant with an <literal>E</>.
</para>
<para>
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.167 2010/05/30 18:10:41 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.168 2010/07/20 00:34:44 rhaas Exp $
*
*-------------------------------------------------------------------------
*/
*/
int backslash_quote = BACKSLASH_QUOTE_SAFE_ENCODING;
bool escape_string_warning = true;
-bool standard_conforming_strings = false;
+bool standard_conforming_strings = true;
/*
* Set the type of YYSTYPE.
* Written by Peter Eisentraut <peter_e@gmx.net>.
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.562 2010/07/16 22:25:50 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.563 2010/07/20 00:34:44 rhaas Exp $
*
*--------------------------------------------------------------------
*/
GUC_REPORT
},
&standard_conforming_strings,
- false, NULL, NULL
+ true, NULL, NULL
},
{
#escape_string_warning = on
#lo_compat_privileges = off
#sql_inheritance = on
-#standard_conforming_strings = off
+#standard_conforming_strings = on
#synchronize_seqscans = on
# - Other Platforms and Clients -