On May 19, 2010, at 18:32 , Robert Haas wrote:
> On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>>> I think it just depends on whether we're likely to get releases from
>>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>>> not sure their schedule will be affected by whether we call it 8.5 or
>>> 9.0.
>>
>> that's a fair point (like I expect debian to provide 9.0 as a backport)
>> though the packages could just change the default for that backport.
>> The precedence for that is standard_conforming_strings which we now have
>> for a while(since 8.2 iirc) - though I don't think we have a firm plan
>> on when we are actually going to turn it on...
>> Not sure if we really need to wait 4 major releases to allow driver
>> developers to adapt...
>> So one idea would be to turn it off for 9.1 and enable that and scs for
>> 9.1 and try to get driver developers attention early in the release cycle.
>
> I think we previously discussed flipping standard_conforming_strings
> at the beginning of the 9.1 cycle, and I'm still OK with that. Not
> sure it bears on the present issue, though.
Well, since both issues are related in that they deal with data representation and force driver upgrades and/or
reviewingand testing of application code to ensure correct encoding and decoding, flipping both defaults simultaneously
mightreduce the overall effort required. If 9.0 ships with the new bytea encoding enabled by default, people will need
toadapt applications for 9.0 to deal with bytea issues and then again for 9.1 to deal with string encoding issues.
Since updated drivers can choose to override the default on a per-connection basis if they're ready to deal with the
newrepresentation, flipping the default doesn't have much of a performance advantage either.
So +1 for flipping both with the release of 9.1, and warning people well ahead of time. Maybe there could even be a
warningin the 9.0 release notes about the scheduled change?
best regards,
Florian Pflug