Re: PG 9.0 and standard_conforming_strings - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PG 9.0 and standard_conforming_strings
Date
Msg-id 603c8f071002031020o266eb0a4vf32e67c2a36d229a@mail.gmail.com
Whole thread Raw
In response to Re: PG 9.0 and standard_conforming_strings  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: PG 9.0 and standard_conforming_strings
Re: PG 9.0 and standard_conforming_strings
Re: PG 9.0 and standard_conforming_strings
Re: PG 9.0 and standard_conforming_strings
List pgsql-hackers
On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
> Perl (DBD::Pg anyway) has been compatible since May 2008.

I would interpret that to mean that there is a significant possibility
that a too-old DBD::Pg could get used with a new PostgreSQL, and
therefore we shouldn't change anything for 9.0.  May 2008 is not that
long ago, especially for people running systems like RHEL with
five-year major release cycles.

I am not sure I really understand why anyone is a rush to make this
change.  What harm is being done by the status quo?  What benefit do
we get out of changing the default?  The major argument that has been
offered so far is that "if we don't change it now, we never will", but
I don't believe that the tenor of this discussion supports the
contention that Tom or anyone else never wants to make this change.

It also seems to overlook the fact that we are STILL dealing with the
fallout from this change in the core code; Tom gave examples upthread
of changes that are being released for the first time *in 9.0* to
address problems created by this transition.  And that is just the
core code; we have to expect that third-party code will lag behind.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: use of dblink_build_sql_insert() induces a server crash
Next
From: Alex Hunsaker
Date:
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]