[DB-SIG] Improved support for prepared SQL statements
SF Markus Elfring
elfring at users.sourceforge.net
Wed Dec 17 14:50:47 CET 2014
> How about:
> The prepared operation is only available until the next call to
> one of the .execute*() methods or another call to the .prepare()
> method using a different command string than the one used for
> preparing the previous operation.
Can the prepare() method return a handle for a SQL statement?
Will prepared SQL statements be mapped to a specific class hierarchy
> It is possible to open a few cursors, prepare frequently
> used statements on them and them make them accessible via
> a cursor pool. This works well (I know since I've implemented
> such a logic some 14-15 years ago in a large application).
How should the application programming interface look like
in Python for this use case?
> The DB-API standard extensions were added to address proliferation
> of such additions. If possible, the database modules should try
> to standardize on these extensions, which is why discussions such
> as these are useful.
Are there more software improvements in a waiting queue?
More information about the DB-SIG