PQescapeByteaConn and the new hex encoding
Hi everyone,
I've been playing with the 8.5alpha3 in the last few days. Among other
things, I'm making sure that the pgsql PHP extensions still work
correctly with the new version. It would seems so, as all the errors in
the standard pgsql extension test suite come from the fact that
PQescapeByteaConn now defaults to the new "hex" format when connected to
a 8.5+ server, which is cool. It's just a matter of updating the tests.
However, before taking a look at the actual code and understanding its
behaviour, I tried using "SET bytea_output = 'escape'" and I was
expecting PQescapeByteaConn to honour it. Not sure if changing the
current behaviour is at all possible, desirable and really worth it, but
I'm going to hold the patches to the php test suite until I get some
feedback here.
Thoughts?
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Matteo Beccati <php@beccati.com> writes:
However, before taking a look at the actual code and understanding its
behaviour, I tried using "SET bytea_output = 'escape'" and I was
expecting PQescapeByteaConn to honour it.
Why? PQescapeByteaConn's charter is to produce something that will work
on the given connection, no more and no less.
regards, tom lane
Il 25/12/2009 18:54, Tom Lane ha scritto:
Matteo Beccati<php@beccati.com> writes:
However, before taking a look at the actual code and understanding its
behaviour, I tried using "SET bytea_output = 'escape'" and I was
expecting PQescapeByteaConn to honour it.Why? PQescapeByteaConn's charter is to produce something that will work
on the given connection, no more and no less.
Makes complete sense :)
I was just trying to find a way to get the PHP function pg_escape_bytea
(which uses PQescapeByteaConn if available) to generate a backwards
compatible escaped string. It's probably just a corner case though and
it can be dealt with at the client side, if necessary.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Matteo Beccati wrote:
Il 25/12/2009 18:54, Tom Lane ha scritto:
Matteo Beccati<php@beccati.com> writes:
However, before taking a look at the actual code and understanding its
behaviour, I tried using "SET bytea_output = 'escape'" and I was
expecting PQescapeByteaConn to honour it.Why? PQescapeByteaConn's charter is to produce something that will work
on the given connection, no more and no less.Makes complete sense :)
I was just trying to find a way to get the PHP function
pg_escape_bytea (which uses PQescapeByteaConn if available) to
generate a backwards compatible escaped string. It's probably just a
corner case though and it can be dealt with at the client side, if
necessary.
There is plenty of reason to use hex format wherever possible - we
expect it to be much more efficient to process on the server side.
cheers
andrew