Re: PG 9.0 and standard_conforming_strings

On Wed, Feb 3, 2010 at 1:46 PM, Greg Sabino Mullane <greg(at)turnstep(dot)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.
>
> That's a silly conclusion. Applications and drivers are always going to
> lag behind. If someone is having a problem, they either upgrade their
> DBD::Pg or flip the GUC. Are you really saying we should wait
> until 2008 +5 years (2013!) before making this change? Wouldn't we have
> to wait five years past the point when *all* drivers are compatible
> by your definition?

I don't think it's a silly conclusion at all, though it's possible
that I am a silly person. The longer we wait before making an
incompatible change, the more people will have adjusted their code to
the new reality (or upgraded their drivers, etc.) and the fewer things
will break. Taking this argument to its illogical extreme, we should
never change anything at all, but I'm not proposing that. What I am
saying is that I got all of the standard_conforming_strings problems
in my own code (that I know about) fixed about a year ago, and it does
not seem implausible to think that there could be people in the world
who take longer to upgrade than I do. In fact, it seems
overwhelmingly likely.

Kevin Grittner made a good point upthread: the harm in NOT changing
standard_conforming_strings is that we will endure for a longer period
of time with strings that, well, don't conform to the standard, which
may cause problems for people trying to migrate to PostgreSQL from
other database systems. Conversely, the harm in changing it is that
it may break existing PostgreSQL applications that run just fine on
older releases. The second problem is something that we can expect to
gradually decrease over time because of (1) the incredibly annoying
escape_string_warning behavior and (2) software version upgrades.
Exactly when the risk is low enough to make the change is a judgement
call.

>> 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.
>
> Which fallout are we still dealing with? Are you saying that the
> developers are not up to the challenge of handling this before 9.0
> is released? (If this were anything more than a simple boolean GUC
> fix, I would be in your corner).

http://archives.postgresql.org/pgsql-hackers/2010-01/msg02992.php

> Yes, third-party code will lag behind, but, again, that's the nature of
> the game. We didn't wait for every driver, app, and script to support
> schemas before we added them in 7.4, for example. We certainly didn't
> wait for applications to be implicit casting ready before 8.3, to (over?)use
> another example.

Implicit casting was in some ways less of a big deal than this change,
at least for me. It broke some things, but they all BROKE, and then I
fixed them. When this standard_conforming_strings thing hit, all of
my scripts that run out of cron started pouring out warning messages
which I initially could not figure out how to get rid of. IIRC,
whatever version of Fedora I was running at the time had a version of
PostgreSQL that generated these stupid warnings, and a version of
DBD::Pg that hadn't yet been updated. It was thoroughly miserable.
Yeah, I probably could have gotten around it by writing my own custom
escaping function or downloading DBD::Pg off of CPAN and compiling it,
but at the time I didn't even understand whether that would actually
fix the problem.

Plus, I'm not sure anyone here would be willing to advocate the way
that the implicit casting stuff went down as a model for future
changes of similar type.

...Robert