--- Carsten Haese <[EMAIL PROTECTED]> wrote: > On Sat, 11 Feb 2006 09:41:41 -0800 (PST), David > Rushby wrote > > --- Carsten Haese <[EMAIL PROTECTED]> wrote: > > > I'm -1 on introducing a whole new class to > encapsulate these deeper > > > diagnostics. > > > [...] > > > If the programmer needs more than one prepared > statement, nothing is > > > stopping them from creating more than one > cursor. > > > > But this is akin to limiting Connections to having > one Cursor open > > at a time, and saying, "if the programmer needs > more than one cursor, > > nothing is preventing them from creating more > than one connection." > > That's a weak analogy. A connection implies a > transaction, ...
A connection only implies a transaction when autocommit is either set to true or when a non-autocommit connection is opened, used, committed/rolled back, and finally closed. But what about the case where a connection is cached, as in a connection pool? Pooled connections are used for multiple transactions over time. In the java world, PreparedStatements are often pooled as well. As such, David's analogy seems valid to me. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
