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:
@ -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
|
||||
|
@ -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>
|
||||
|
Reference in New Issue
Block a user