Re: PQescapeByteaConn and the new hex encoding

Lists: pgsql-hackers
From: Matteo Beccati <php(at)beccati(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: PQescapeByteaConn and the new hex encoding
Date: 2009-12-25 17:12:51
Message-ID: 4B34F293.80906@beccati.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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/


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PQescapeByteaConn and the new hex encoding
Date: 2009-12-25 17:54:26
Message-ID: 7336.1261763666@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Matteo Beccati <php(at)beccati(dot)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


From: Matteo Beccati <php(at)beccati(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PQescapeByteaConn and the new hex encoding
Date: 2009-12-25 18:17:43
Message-ID: 4B3501C7.4070901@beccati.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Il 25/12/2009 18:54, Tom Lane ha scritto:
> Matteo Beccati<php(at)beccati(dot)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/


From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PQescapeByteaConn and the new hex encoding
Date: 2009-12-25 18:36:38
Message-ID: 4B350636.4010605@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Matteo Beccati wrote:
> Il 25/12/2009 18:54, Tom Lane ha scritto:
>> Matteo Beccati<php(at)beccati(dot)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