And it is 9.0, i.e another major version. IMO the higher major versions not
necessarily must be 100% backward compatible. So, think twice next time
you update the major version.
2010/10/13 Raymond O'Donnell <rod@xxxxxx>
On 13/10/2010 01:37, ljb wrote:In fairness, it *is* flagged in the release note - it's the first item under "data types" in the list of incompatibilities.
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.
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
rod@xxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
// Dmitriy.
