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, and requiring the module user to open a second connection to get a second cursor would render the module utterly useless for most cases except extremely trivial ones. On the other hand, asking the module user to obtain a second cursor to prepare two different statements places no undue burden on them. > It's an arbitrary limitation with dubious benefit. The DB API > doesn't impose such a limitation in the case of cursors; why do so with > prepared statements? Of course it's arbitrary, any standard is arbitrary, but it is not a limitation of usability or an impediment to code readability. The proposal of adding an optional .prepare() method and the additional diagnostic attributes on the cursor fits well with the existing API. Adding a whole new class for functionality that can be provided by optional methods and attributes on the cursor is an arbitrary complication with dubious benefit. > > cursor.description already gives the programmer information about the > > output parameters. > > But currently it's only available after execution. Would you make > .description available as a result of a .prepare call, even if > .executeXXX hadn't been called yet? > > If the standard is going to cover statement preparation, it seems > sensible to me to separate preparation from execution to the extent > that any information available after preparation but before execution > is exposed as soon as possible. That's the idea. If a module implements .prepare(), .description and the suggested additional attributes (.input_description, .statement_type, etc., if they're implemented) should be made available after .prepare(). I was remiss in not stating this explicitly. > > Input parameters and the query plan may be hard to standardize in > > a meaningful way... > > I agree that the query plan would be impossible to standardize. > > But standardizing a metadata representation of input parameters > shouldn't be hard. It's already done for output parameters with > .description, and input parameters shouldn't theoretically be any > more difficult, right? JDBC supports metadata for both input and output > parameters. I agree, it should be possible to apply the same semantics of .description to .input_description. Best regards, Carsten. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
