Thanks for your reply Daniel.
The escaped characters are causing problems for instance in this query:
INSERT INTO REGISTER (studentid, code) VALUES ('5632', '\')
In psycopg1 this works perfectly. In psycopg2 the \ escapes the next character and causes a syntax error at the postgres level. At least this is what I think is happening.. the versions of postgres I am testing on are the same - 8.1, and Zope above that. I am concerned that altering how postgres escapes characters would cause problems elsewhere. Do you advise to upgrade to psycopg2 in production environment ?
Thanks
Richard
On Thu, Jan 13, 2011 at 6:15 PM, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
On Thu, Jan 13, 2011 at 5:37 PM, Richard Harley
<
raharley0@googlemail.com> wrote:
> Hello all
>
> I've noticed Psycopg2 handles escaping backslashes differently to
> Psycopg1. Currently we use psycopg1 in a large school registration
> system which uses a lot of these (think AM / PM \). I think the DA is
> sending them though to postgres as \\. But psycopg2 is escaping the next
> character - ('a','b','c','/<----) causing issues. On one hand I want to
> upgrade to psycopg2 because I know 1 is getting on a bit now...but it
> works for the job. Do I need to be overly concerned about how old
> Psycopg1 is now? Is upgrading to 2 going to be worth the headache?
I'm not getting exactly what is the escaped character causing
problems: could you send a more detailed example? The query and
arguments you are executing, what are you expecting to receive on the
postgres side and what you are really receiving (it may be handy to
bump the PG logging level to log all the statements fora while in
order to obtain these informations). I am not really expecting the
escaped version of the query to be used for anything else but for the
database to run it, so your report surprises me.
Also, what postgres version are you using? Escaping rules are
different according to the standard_conforming_string setting and
whether your PG version supports it.
-- Daniele
