PG 9.0 and standard_conforming_strings
in [PgSql]
|
Prev: [HACKERS] PG 9.0 and standard_conforming_strings
Next: Package namespace and Safe init cleanup for plperl [PATCH]
From: "Kevin Grittner" on 30 Jan 2010 08:30 Tom Lane wrote: C�dric Villemain wrote: >> Do you mean that turning standard_conforming_string ON may lead to >> error with pg_dump, psql or something else ? > Maybe. We concluded in the April 2009 thread that > standard_conforming_strings = ON had gotten little or no field > testing, Well, we've been using it in hundreds of databases as our standard setting in postgresql.conf since February, 2006. We've used pg_dump with it many hundreds of times, and tens of millions of JDBC transactions per day since then. We use psql heavily, too. Not a single sign of problems with it. Surely that bumps the needle above "little or no field testing". Certainly there are PLs and PostgreSQL features we don't use which should be tested first, but let's not overstate the case. > An actual plan here might look like "let's flip it before 9.1alpha1 > so we can get some alpha testing cycles on it" ... That sounds sane. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Euler Taveira de Oliveira on 30 Jan 2010 09:55 Peter Eisentraut escreveu: > Maybe the next step should be to leave standard_conforming_strings off > but make the warning an error. > It will break application in the same way as enabling the parameter. Besides that the parameter should be renamed to escape_string_*error* to reflect the fact that it doesn't emit an error anymore. I don't think it is a good idea. The main problem of enabling standard_conforming_strings is that applications and/or programming language DB APIs are not prepared to support this. I don't see a change in DB APIs (that I know of -- Python, Perl, and PHP) to add support for producing a string according to standard_conforming_strings parameter. IMHO we need to encourage such languages to modify their functions so we can produce strings according to this parameter. These change will minimize the number of problems in applications. Of course, there will be some problems in those applications that doesn't use the escape function of the DB API but they could always disable this parameter. ;) As for enabling it by default, I'm afraid we will have to wait a few cycles of development because of those changes in DB APIs. A reasonable target is 10.0. ;) -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 30 Jan 2010 11:16 Euler Taveira de Oliveira <euler(a)timbira.com> writes: > Peter Eisentraut escreveu: >> Maybe the next step should be to leave standard_conforming_strings off >> but make the warning an error. >> > It will break application in the same way as enabling the parameter. Besides > that the parameter should be renamed to escape_string_*error* to reflect the > fact that it doesn't emit an error anymore. I don't think it is a good idea. Yeah, I agree. Such a change wouldn't do anything to help with testing of the standard_conforming_strings = on case. What it would do is render the s_c_s = off case entirely useless, unless one also disabled the error, which pretty much every single user would immediately do. We might as well just flip the s_c_s setting. People who don't want to be bothered will still undo the setting change, but at least then our default behavior is more standard rather than even less so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Albe Laurenz" on 2 Feb 2010 04:13 Mark Mielke wrote: > On 01/29/2010 09:01 PM, Tom Lane wrote: > > Maybe. We concluded in the April 2009 thread that > > standard_conforming_strings = ON had gotten little or no field testing, > > and I don't see any strong reason to hope that it's gotten much more > > since then. > > Not to contradict any justifiable investigation, but just as > a data point: > > All of my installations use: > > backslash_quote = off # on, off, or safe_encoding > escape_string_warning = off > standard_conforming_strings = on > > I have not encountered any problems so far. I use PostgreSQL in about 10 > production applications (too tired to count them out :-) ), from psql to > PHP to Perl to Java. I had also assumed this feature was tested and > supported when I enabled it, as it seemed to me to be the only sensible > implementation, and it was consistent with my interpretation of SQL. I > had done some testing before enabling it the first time and was > satisfied with the results. FWIW, I also turn it on by default in my company's installations and revert it if there are problems. These problems are usually carelessly written third party applications. We discovered one omission in Npgsql which was fixed quickly. To the best of my knowledge, JDBC and Npgsql are ready for standard_conforming_strings=on. I am all for changing it as soon as reasonably possible. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Greg Sabino Mullane" on 3 Feb 2010 12:34
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > The main problem of enabling standard_conforming_strings is > that applications and/or programming language DB APIs are > not prepared to support this. I don't see a change in DB > APIs (that I know of -- Python, Perl, and PHP) to add > support for producing a string according to > standard_conforming_strings parameter. Perl (DBD::Pg anyway) has been compatible since May 2008. As one of the more vocal critics of the 8.3 implicit casting incident, I say +1 on making the change. Unlike casting, it's a simple GUC change to "fix", and now (9.0) is the time to do it. - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201002031233 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktps4oACgkQvJuQZxSWSshAIgCg6wxvgVasOksQ8JQaFOeaSQEu zZwAn0UqIG7Oti6BJVeJYTEx6b7VsZjf =HJcB -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |