From: Tom Lane on
=?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

> 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
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
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
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