2010/1/30 Tom Lane <tgl@sss.pgh.pa.us>:
> Cédric Villemain <cedric.villemain.debian@gmail.com> writes:
>> 2010/1/29 Tom Lane <tgl@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