On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall <ktm@rice.edu> wrote:
> On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
>> On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
>> <stefan@kaltenbrunner.cc> wrote:
>> > On 05/19/2010 08:13 AM, Tom Lane wrote:
>> >> Bernd Helmle <mailings@oopsware.de> writes:
>> >>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh <jesper@krogh.cc> wrote:
>> >>>> May I ask whats the reason is for "breaking" the compatibillity?
>> >>
>> >>> "Efficency", if i am allowed to call it this way. The new hex
>> >>> representation should be more efficient to retrieve and to handle than the
>> >>> old one. I think bytea_output was set to hex for testing purposes on the
>> >>> first hand, but not sure wether there was a consensus to leave it there
>> >>> finally later.
>> >>
>> >> Yeah, we intentionally set it that way initially to help find stuff that
>> >> needs to be updated (as DBD::Pg evidently does). ?It's still TBD whether
>> >> 9.0.0 will ship with that default or not.
>> >
>> > given how much faster the new format is (or rather how slow the old one
>> > was) and the number of people I have seen complaining "why is bytea so
>> > slow) I would like to see it staying turned on by default. However this
>> > also depends on how quickly database driver developers can adapt.
>>
>> I would favor waiting a release to turn it on by default, precisely to
>> give driver developers time to adapt.
>>
> Changing something like that within the minor release arc is
> not a good idea. It would be better to have it on by default and
> if the driver developers are not up to use it, they can have that
> as a setting that they will need to change when going to 9.0. I
> would be very upset to have a minor upgrade break my database. At
> least the major upgrades have more testing.
I meant, wait for the next MAJOR release to turn it on by default.
Changing it in a minor release is clearly a bad idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company