Message-ID: <4CB563B6.8020803@iol.ie>
Date: Wed, 13 Oct 2010 08:45:58 +0100
From: Raymond O'Donnell <rod@iol.ie>
Reply-To: rod@iol.ie
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
	rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1
MIME-Version: 1.0
To: ljb <ljb9832@pobox.com>
CC: pgsql-general@postgresql.org
Subject: Re: Gripe: bytea_output default => data corruption
References: <i92v0d$qfe$1@news.hub.org>
In-Reply-To: <i92v0d$qfe$1@news.hub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 13/10/2010 01:37, ljb wrote:
> Defaulting bytea output from the backend to use hex mode encoding, which is
> incompatible with pre-9.0 interfaces, wasn't a friendly thing to do. The
> default should have been escape mode. Or else you needed a big warning in
> HISTORY that we must either change bytea_output, or upgrade all clients
> before servers. Because using a 9.0 server with a 8.x libpq-based client
> results in undetected data corruption when selecting BYTEA objects.
>
> By default, the 9.0 server encodes a bytea using hex mode, but an 8.x
> libpq-based client will decode that using escape mode, with no error detected
> on either end. For example, start with "A", encode to "\x40" decode to "x40".
>
> There are good reasons to break backward compatibility, like security or
> standards compliance, but not performance.  Please think twice next time you
> consider breaking stuff just because you think the new way should be faster.

In fairness, it *is* flagged in the release note - it's the first item 
under "data types" in the list of incompatibilities.

Ray.

-- 
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie