standard_conforming_strings
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
An actual plan here might look like "let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it" ..."Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."
Should we do this? Patch attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Attachments:
standard_conforming_strings_on.patchtext/x-patch; charset=US-ASCII; name=standard_conforming_strings_on.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 1aff181..13a39be 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -5203,11 +5203,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
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 9f2c73b..45e0e9e 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -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>
diff --git a/src/backend/parser/scan.l b/src/backend/parser/scan.l
index 903efee..aec94be 100644
--- a/src/backend/parser/scan.l
+++ b/src/backend/parser/scan.l
@@ -52,7 +52,7 @@
*/
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.
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index e839639..83e8517 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1209,7 +1209,7 @@ static struct config_bool ConfigureNamesBool[] =
GUC_REPORT
},
&standard_conforming_strings,
- false, NULL, NULL
+ true, NULL, NULL
},
{
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index a3b1457..9b06cd4 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -509,7 +509,7 @@
#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 -
Robert Haas wrote:
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
An actual plan here might look like "let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it" ..."Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."Should we do this? Patch attached.
+1
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
An actual plan here might look like "let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it" ..."Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."
Should we do this? Patch attached.
I'm still scared to death of the security implications, but if we don't
do it now, when will be a better time? Might as well try it and see
what breaks. Note there had better be a large compatibility warning in
the alpha release notes, and we had better pester driver authors to test
with 9.1alpha1 as soon as it's out.
regards, tom lane
On 14/07/10 15:48, Robert Haas wrote:
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus<josh@agliodbs.com> wrote:
An actual plan here might look like "let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it" ..."Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."Should we do this? Patch attached.
Any reason not to add a line to the 9.0 docs/release notes saying
"WARNING: The PGDG currently plan to change this setting's default in 9.1"?
--
Richard Huxton
Archonet Ltd
On Jul 15, 2010, at 12:30 AM, Richard Huxton <dev@archonet.com> wrote:
On 14/07/10 15:48, Robert Haas wrote:
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus<josh@agliodbs.com> wrote:
An actual plan here might look like "let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it" ..."Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."Should we do this? Patch attached.
Any reason not to add a line to the 9.0 docs/release notes saying "WARNING: The PGDG currently plan to change this setting's default in 9.1"?
Well, mostly that we could change our mind if it makes too big a boom. And it's not as if we could go back and update everyone's docs after-the-fact. I agree we need some press, but the docs are not the right vehicle.
...Robert
Robert Haas <robertmhaas@gmail.com> writes:
On Jul 15, 2010, at 12:30 AM, Richard Huxton <dev@archonet.com> wrote:
Any reason not to add a line to the 9.0 docs/release notes saying "WARNING: The PGDG currently plan to change this setting's default in 9.1"?
Well, mostly that we could change our mind if it makes too big a boom.
And it's not as if we could go back and update everyone's docs
after-the-fact.
Yeah. Our track record for predicting in the version-N docs what
changes will be made in version N+1 is spectacularly bad; we should
not try that here, even if the change is being made before 9.0 actually
goes final. There is already a statement that the default will change
"in a future release", and that seems sufficient to me.
regards, tom lane
On ons, 2010-07-14 at 10:48 -0400, Robert Haas wrote:
On Fri, Jan 29, 2010 at 10:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
An actual plan here might look like "let's flip it before 9.1alpha1
so we can get some alpha testing cycles on it" ..."Hey, let's flip it in 9.1 CF 1, so that we can have some alpha testing
cycles on it."Should we do this? Patch attached.
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.
Do both. Turn them on, then make a list and inform driver maintainers who need to update. They've got a year, after all.
Best,
David
"David E. Wheeler" <david@kineticode.com> writes:
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.
Do both. Turn them on, then make a list and inform driver maintainers who need to update. They've got a year, after all.
Yeah. If we wait for driver authors to do something, we'll never make
this change at all. The idea of committing it now is to give them a
shove, *and* enough time to respond.
regards, tom lane
On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.Do both. Turn them on, then make a list and inform driver maintainers who need to update. They've got a year, after all.
Here we go then:
http://wiki.postgresql.org/wiki/Standard_conforming_strings
On Mon, Jul 19, 2010 at 5:04 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.Do both. Turn them on, then make a list and inform driver maintainers who need to update. They've got a year, after all.
Here we go then:
http://wiki.postgresql.org/wiki/Standard_conforming_strings
Looks like a good start. We might want to make an "open items for
9.1" page and, as a first such open item, add a link to this page.
Since it seems we have consensus, I will commit the patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Mon, Jul 19, 2010 at 8:32 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jul 19, 2010 at 5:04 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.Do both. Turn them on, then make a list and inform driver maintainers who need to update. They've got a year, after all.
Here we go then:
http://wiki.postgresql.org/wiki/Standard_conforming_stringsLooks like a good start. We might want to make an "open items for
9.1" page and, as a first such open item, add a link to this page.Since it seems we have consensus, I will commit the patch.
So it turns out that (at least) the hstore and ECPG regression tests
depend on the default setting of standard_conforming_strings. I have
taken a crack at fixing this...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On 7/20/10, Peter Eisentraut <peter_e@gmx.net> wrote:
On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make, say, a list of driver versions and
application versions that work with standard_conforming_strings = on,
and then decide based on that, and also make that list a public resource
for packagers etc.Do both. Turn them on, then make a list and inform driver maintainers who need to update. They've got a year, after all.
Here we go then:
http://wiki.postgresql.org/wiki/Standard_conforming_strings
There is two sorts of support:
1. Detect stdstr on startup and use that setting.
2. Detect online changes to stdstr and follow them.
AFAICS psycopg does not support 2). Should we care about that?
There are probably other drivers with partial support.
--
marko
On tis, 2010-07-20 at 13:31 +0300, Marko Kreen wrote:
There is two sorts of support:
1. Detect stdstr on startup and use that setting.
2. Detect online changes to stdstr and follow them.
AFAICS psycopg does not support 2). Should we care about that?
There are probably other drivers with partial support.
I think a driver could also just use E'' when it sees a backslash in the
string.