Re: Stuff for 2.4.1

On Sun, Mar 27, 2011 at 12:51 PM, Harald Armin Massa
<harald(at)2ndquadrant(dot)com> wrote:
> Daniele,
>
>> own parser for the bytea hex format, so that clients are no more >dependant on libpq 9 to talk with a 9 server.
>>By the way the best way to make  this patch
>>was to have our own parser for the "escape" format as well:
>> this has generally improved performance in receiving bytea
>
> compliments for doing performance improvements!
>
> Are you really sure that psycopg2 should go the road of having own
> parsers in addition to libpq-s routines? As much as I am happy about
> the robustness when having other libpqs, and about the performance
> benefit, as much I fear to have some new areas for possible bugs -
> especially security-relevant things like SQL-injections.

Hi Harald,

The will to stick as much as possible to the libpq functions has been
the reason I had not written the above parser before (releasing
2.4.0). Unfortunately the bytea problem has proven trickier to handle
for many psycopg users. I've changed my mind as I think psycopg has
the responsibility to provide a set of feature in a robust way, and if
the libpq is just not reliable for bytea parsing (for me the hex
format should have been backported to the the client libraries of the
previous versions) I think we have to provide a solution, not just to
propagate the problem.

Please note that I have not written a parser for user input: this is a
parser specifically used to receive data from the database and is only
used to parse the bytea *output* format
(http://www.postgresql.org/docs/9.0/static/datatype-binary.html). I
would be very concerned in replacing PQescapeString/PQescapeBytea for
the reason you mention, and I would never do it to gain performance:
I've just replaced PQunescapeBytea to solve the problem of PG 9.0
communication, and the performance improvement is only a side effect,
not something I was after.

Of course the code is available for review
<https://github.com/dvarrazzo/psycopg/blob/devel/psycopg/typecast_binary.c>.

Regards,

-- Daniele