On Mon, Jan 30, 2017 at 9:51 PM, Aryeh Leib Taurog <python@aryehleib.com> wrote:
> I haven't dug into PQexecParams, but it seems to me that these
> alternate strategies could be made available outside of psycopg2.
I got to the same conclusion, so I've implemented functions to
implement the functions execute_batch() and execute_values() (resp.
what you call "joined" and "folded" in your benchmarks) in the extras
module, and leave the semantics of executemany() untouched (no extra
parameters or rowcount breaking only if going batched... just too
confusing).
Implementation, docs, tests in `this commit`__.
.. __: https://github.com/psycopg/psycopg2/commit/a95fd3df1abc0282f1c47fa2170191f037c3c8de
I also thought about implementing an execute_prepared() function,
which would have run PREPARE, then EXECUTE in a loop (possibly batched
as in execute_batch), finally DEALLOCATE. Implementation doesn't seem
trivial because:
- parameters %s and %(name)s should be replaced with $1, $2, ..., with
matching unescaping of literal % and escaping of literal $;
- in case of error, calling DEALLOCATE is tricky: if the connection is
not autocommit the transaction is failed, the function could use a
savepoint but then it would clear the error state too; not calling
DEALLOCATE would leave the prepared statement there and according to
the name chosen for the statement (e.g. 'psycopg_%s' % id(cursor))
would make another execute_prepared() fail... it should be possible to
wrap the PREPARE in a savepoint to deal with this problem;
- if the connection is autocommit all the above is not needed.
ISTM that it's easier to leave the users to call
PREPARE/execute_batch('EXECUTE')/DEALLOCATE: knowing the context in
which the sequence is called wouldn't require parameters mangling and
the error management would be simpler for them.
Thoughts? Shall we merge this stuff? Any feedback is welcome.
-- Daniele