[DB-SIG] Improved support for prepared SQL statements

[Michael Bayer]

> On Dec 18, 2014, at 5:39 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
> On 17.12.2014 19:13, INADA Naoki wrote:
>> As I said before, prepared statement is normally bound to connection.
>> So `.prepare()` method should be connection's method, not cursor's.
>> 
>> prepared = conn.prepare("SELECT ?+?")
>> ...
>> cur = conn.cursor()
>> cur.execute(prepared, (1, 2))
>> cur.fetchone()  # returns (3,)
> 
> I'm not sure which database you are talking about, but in terms
> of concepts, statements are run on cursors, so adding the method
> to connections doesn't look right (we dropped this logic when moving
> from DB-API 1.0 to 2.0 a long time ago).
> 
> Also note that the prepare step may need access to the
> cursor configuration settings to be correctly interpreted
> by the database.

oh, so are you saying that if one produces a prepared statement from a cursor, and then that cursor is closed, I have no option to re-use that prepared statement anywhere else, is that right?  

That would make the entire feature a non-starter for me.    SQLAlchemy doesn’t hold cursors open beyond a single statement.    My users would very much want a prepared-statement-per-transaction object.

JDBC provides prepared statements as a service of the Connection.    I think DBAPI should be doing the same.