Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread Tony Locke
Mike, I agree. You quote: "The first time you pass a statement to the cursor's execute() method, it prepares the statement. For subsequent invocations of execute(), the preparation phase is skipped if the statement is the same.” This is basically what pg8000 does but I've found you need a couple

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread Michael Bayer
M.-A. Lemburg wrote: > On 21.12.2014 20:56, Michael Bayer wrote: >> M.-A. Lemburg wrote: >> >>> Whether or not a cursor is client or server side depends on many >>> things and is generally database backend specific. MS SQL Server >>> for example will default to server side cursors and revert

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread M.-A. Lemburg
On 21.12.2014 20:56, Michael Bayer wrote: > > > M.-A. Lemburg wrote: > >> >> Whether or not a cursor is client or server side depends on many >> things and is generally database backend specific. MS SQL Server >> for example will default to server side cursors and revert to >> client side for s

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread M.-A. Lemburg
On 21.12.2014 20:46, Michael Bayer wrote: > M.-A. Lemburg wrote: >>> However, getting back to the issue of prepared statements, I will note that >>> specific to MySQL, MySQL’s own DBAPI driver, MySQL-connector-Python, does in >>> fact tie the prepared statement to the cursor: >>> http://dev.mysql.

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread Michael Bayer
M.-A. Lemburg wrote: > > Whether or not a cursor is client or server side depends on many > things and is generally database backend specific. MS SQL Server > for example will default to server side cursors and revert to > client side for some special cases: > > http://msdn.microsoft.com/en-u

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread Michael Bayer
M.-A. Lemburg wrote: > > Just to clarify: both MS SQL Server and IBM DB2 use ODBC as their > native database interface C API. > > They have both extended it to include some special features which > are not part of the ODBC standard, but in way that's compatible > with ODBC. Just look at the s

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread M.-A. Lemburg
On 19.12.2014 00:12, Michael Bayer wrote: > M.-A. Lemburg wrote: >> I think there's a misunderstanding here. A named cursor refers to >> a database cursor pointing into a result set. Once that result >> set has been created and the cursor points to it, you cannot >> run another .execute() against

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread M.-A. Lemburg
On 21.12.2014 19:40, Michael Bayer wrote: > > > M.-A. Lemburg wrote: > >> >> My experience is from working with ODBC and ODBC drivers. >> IBM DB2 and MS SQL Server use ODBC as their native database >> interface API. In ODBC, cursors are called "statements" and >> you have two modes of operation

Re: [DB-SIG] Improved support for prepared SQL statements

2014-12-21 Thread Michael Bayer
M.-A. Lemburg wrote: > > My experience is from working with ODBC and ODBC drivers. > IBM DB2 and MS SQL Server use ODBC as their native database > interface API. In ODBC, cursors are called "statements" and > you have two modes of operation: > > a) direct execution, which sends the SQL straig