On Tue, May 31, 2011 at 12:47 PM, Marko Kreen <markokr@gmail.com> wrote:
> And the proper fix is quite well-known: $x placeholders
> and Extended Query protocol.
Do you have ideas about how to avoid breaking applications where
people have used multiple queries in an execute? Or how to pass arrays
in a robust way when the suggested method (ARRAY[] construct) doesn't
work with PQexecParams? Or to make IN work?
I've already called for discussion a couple of months ago [1] about
supporting the EQ protocol: it will eventually be done, but the result
will hardly be a complete replacement for what psycopg currently does,
so don't see it becoming the default escape mechanism. (Of course,
while I'm positive about its implementation, nobody has stepped ahead
for implementing it, so I'm afraid it will have to wait for a slice of
my Copious Spare Time).
While it's good stuff the EQ exists for applications directly using
the libpq, It wouldn't have saved many troubles for psycopg: IMO this
one is really borderline to a pathological case and is not a security
issue.
If there was a psycopg3 to be written with no backward compatibility
to maintain, the EQ protocol would be a reasonable choice. Of course
it wouldn't offer the above features, no mogrify(), no cursor.query
and so on, but that would be tolerable for a new driver with a
different features set. But just putting EQ into psycopg2 simply means
dropping features and causing problems to a random bunch of users: I
don't see dropping such features just to use the EQ a victory overall.
-- Daniele
[1] http://archives.postgresql.org/psycopg/2011-02/msg00076.php