[DB-SIG] query - prepared statment

Carsten Haese carsten at uniqsys.com
Sat Feb 11 22:15:21 CET 2006

On Sat, 11 Feb 2006 09:41:41 -0800 (PST), David Rushby wrote
> --- Carsten Haese <carsten at uniqsys.com> 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

Best regards,


More information about the DB-SIG mailing list