Prev: [HACKERS] PG 9.0 and standard_conforming_strings
Next: Package namespace and Safe init cleanup for plperl [PATCH]
From: Tom Lane on 29 Jan 2010 21:01 =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric.villemain.debian(a)gmail.com> writes: > 2010/1/29 Tom Lane <tgl(a)sss.pgh.pa.us>: >> We would have more than no-time-at-all to test it and fix any breakage. >> Just to start close to home, do you really trust either psql or pg_dump >> to be completely free of standard_conforming_strings issues? �How about >> JDBC or ODBC? �Python drivers? �PLs? > Do you mean that turning standard_conforming_string ON may lead to > error with pg_dump, psql or something else ? (I don't care of projects > outside the official postgresql tarball in this question) 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. It would be rather surprising if there *aren't* any lurking bugs in one piece or another of client-side code. And I don't think that we should be so myopic as to consider that problems in drivers and so forth are not of concern. I would be all for making this change in an orderly fashion pursuant to some agreed-on plan. But cramming it in at the last minute because of an essentially marketing-driven change of version name isn't good project management, and I'm seriously afraid that doing so would bite us in the rear. An actual plan here might look like "let's flip it before 9.1alpha1 so we can get some alpha testing cycles on it" ... 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: Josh Berkus on 29 Jan 2010 21:02 > 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." ;-) --Josh Berkus -- 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: Mark Mielke on 30 Jan 2010 01:25 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. It would be rather surprising if there *aren't* any lurking > bugs in one piece or another of client-side code. And I don't think > that we should be so myopic as to consider that problems in drivers and > so forth are not of concern. > 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. > I would be all for making this change in an orderly fashion pursuant to > some agreed-on plan. But cramming it in at the last minute because of > an essentially marketing-driven change of version name isn't good > project management, and I'm seriously afraid that doing so would bite > us in the rear. > > An actual plan here might look like "let's flip it before 9.1alpha1 > so we can get some alpha testing cycles on it" ... Yep. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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: Peter Eisentraut on 30 Jan 2010 04:33 On fre, 2010-01-29 at 16:06 -0500, Bruce Momjian wrote: > The way the docs stand now we hold it over people's heads and issue > warnings that are meaningless if we are never going to change it. Maybe the next step should be to leave standard_conforming_strings off but make the warning an error. -- 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: =?ISO-8859-1?Q?C=E9dric_Villemain?= on 30 Jan 2010 07:19
2010/1/30 Tom Lane <tgl(a)sss.pgh.pa.us>: > =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric.villemain.debian(a)gmail.com> writes: >> 2010/1/29 Tom Lane <tgl(a)sss.pgh.pa.us>: >>> We would have more than no-time-at-all to test it and fix any breakage. >>> Just to start close to home, do you really trust either psql or pg_dump >>> to be completely free of standard_conforming_strings issues? How about >>> JDBC or ODBC? Python drivers? PLs? > >> Do you mean that turning standard_conforming_string ON may lead to >> error with pg_dump, psql or something else ? (I don't care of projects >> outside the official postgresql tarball in this question) > > 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. It would be rather surprising if there *aren't* any lurking > bugs in one piece or another of client-side code. And I don't think > that we should be so myopic as to consider that problems in drivers and > so forth are not of concern. Sure, I was just a bit scared because of production servers with standard_conforming_string ON. One interesting thing in this area is that I found very usefull to turn this param ON for windows path. (so perhaps we will have more testing coming from windows users than others ...) > > I would be all for making this change in an orderly fashion pursuant to > some agreed-on plan. But cramming it in at the last minute because of > an essentially marketing-driven change of version name isn't good > project management, and I'm seriously afraid that doing so would bite > us in the rear. I agree and I don't care this parameter is really on or off by default. I just wanted to be sure it is sane enough to use it. > > An actual plan here might look like "let's flip it before 9.1alpha1 > so we can get some alpha testing cycles on it" ... Sounds good. -- Cédric Villemain -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |