1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00

Change the default value of standard_conforming_strings to on.

This change should be publicized to driver maintainers at once and
release-noted as an incompatibility with previous releases.
This commit is contained in:
Robert Haas
2010-07-20 00:34:44 +00:00
parent 0b4a0868f9
commit 0839f312e9
5 changed files with 18 additions and 22 deletions

View File

@ -1,4 +1,4 @@
<!-- $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>
@ -5237,11 +5237,8 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
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

View File

@ -1,4 +1,4 @@
<!-- $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>
@ -445,16 +445,15 @@ SELECT 'foo' 'bar';
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>