Re: contrib: hack for psycopg2 performance

Karsten Hilbert <[email protected]> Wed, 12 May 2010 13:40:24 +0200
Newsgroups gmane.comp.python.db.psycopg.devel
Message-ID <[email protected]>
On Wed, May 12, 2010 at 12:11:25PM +0100, Daniele Varrazzo wrote:

> >> PQexecParams has the shortcoming of being able to send only a query at
> >> time, whereas PQexec allows to send any number in a single string,
> >> separated by semicolons. Many people use this feature and dropping it
> >> would be an incompatible change.
> >
> > While that's understood and appreciated, would it be an
> > option to allow the user to tell psycopg2
> >
> >        "yes, I know I can only use single queries per
> >        invocation but I do want you to use PQexecParams"
> 
> I feel this as a "don't make me choose" case [1].

Absolutely !

But it could beneficially be an "allow-me-to-choose" case.

Psycopg2 would continue to work just as it does right now.

However, if I deliberately go

	import psycopg2
	psycopg2.use_scary_Params_call_and_let_me_shoot_my_foot = True

it would switch to using *Params and let me live with it.

Note that I am not asking for psycopg2 to check and
deliberately except on me should I still try to chain SQL
with ";". I would have to live with whatever consequences
ensue.

> _Assuming_ that psycopg will work fine in both cases, *Params and not *Params (in the
> set of queries accepted by the more restrictive), why should the user
> be loaded with the burden of choosing which one to use?

Because *Params offers a quantitative advantage (speed) and
a qualitative advantage (*ridding* oneself of SQL injection).

Also note that I am not asking the burden the user with the
*requirement* to choose, rather only with the option.

> There is a big fat assumption above, but psycopg doesn't use (anymore)
> its own quoting algorithm, which may be flawed: it is using the libpq
> PQescapeStringConn, so we can assume it is as secure as the backend
> is.

I know but it is more secure to perform the
possibly-safe-possible-unsafe escaping *inside* the server
*inside* the backend because in that case no injection *can*
happen while on the wire *towards* the server.

> > I know I would use that in GNUmed.
> 
> Would you choose the *Param way because you don't trust psycopg in
> performing the right escape or for some other reason?

Because when dealing with your Hep C/HIV lab results or
pregnancy data or transgender operational procedures I'd
rather choose the most secure path possible even if that
should incur a (reasonable) penalty. It is not a matter of
trust (which is quantitative) but rather of
can-or-cannot-happen (as in binary).

I do appreciate the argument of not desiring to support two
code paths.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346