[DB-SIG] Improved support for prepared SQL statements

[Michael Bayer]

> On Dec 7, 2014, at 4:06 PM, SF Markus Elfring <elfring at users.sourceforge.net> wrote:
> 
> I imagine that it will be more efficient occasionally to offer also a
> base class like "prepared_statement" so that the parameter specification
> does not need to be parsed for every passed command.
> I suggest to improve corresponding preparation and compilation
> possibilities.
> https://bugs.python.org/issue22956


IMHO, before we add a complex new interface to the DBAPI, which will greatly add to the workload both of DBAPI authors now asked to support this as well as downstream abstraction layers who will have the same issue, I’d like to request that we have a formal rationale for the addition of this feature as an explicit API.     Looking through this thread, I’ve searched for one, and it appears that this is the only one:  "I **imagine** that it will be more efficient”.

As it happens, I “imagine” that it will make hardly any difference at all, if not perform worse due to the complexity of prepared statements, as well as that it will cause downstream users to write more complicated code in order to deal with attempting to cache these statements.     We use Python because it is a high level scripting language, that foregoes the exposure of low-level details in favor of simplicity of code.

Might we add features to the DBAPI based on concrete benchmarks and observations rather than our imaginations?    Can someone please take up this task and prove to me with benchmarks that this effort will be worthwhile (or at least show me what I’m going to have to put into my documentation as to when these new APIs are appropriate) ?