[DB-SIG] db module wrapper

Mikhail Terekhov terekhov at emc.com
Fri Aug 20 20:04:53 CEST 2004

Vernon Cole wrote:

> I confess, and beg pardon. I let myself wander off from Randall's topic --
> which is creation of a wrapper for various DB API 2.0 packages -- onto the
> topic of creation of DB API 3.0.  Nevertheless, I think that Randall's work
> may help to define 3.0 in some ways.
>   I feel very strongly that the eventual 3.0 must be able to run simple to
> medium querys, and simple adds or updates, using a completly standardized
> syntax.  When one gets to the more complex stuff -- indexing and triggers
> for example -- standardization is out the window. Way out. I think the goal
> of the wrapper is roughly that, too. 
>    Having said all that, is it not true that the role of cursor.execute() in
> the wrapper is not to PARSE an SQL statement, but to BUILD one?

I would say that the role of the cursor.execute() is EXECUTE SQL statement,
not to parse or build one.

>    The four ways now used to encode parameters are all based loosly on the
> principle of an fprintf() function in C. A string with some type of escape
> patterns is passed, followed by a list of parameters. I am trying to suggest
> that we can simplify things by using the power of python. We are using a
> language with strongly typed parameters.  A module implementor can tell at
> run time the data type of the contents of an arbitrary parameter.
> If the cursor.execute() method accepts an arbitrary parameter list, then we
> have no need of escapes.  The application programmer simply breaks his sql
> statement at that point, puts in the python variable he has in mind, and
> then continues the SQL as another string literal. The implementor will
> inject the appropriate escape into the string she is building and prepare
> the paramater for passing as needed by the target SQL engine.

That is impossible in general without full SQL parsing capability.
For example, string quoting may be different (' vs. ") depending on
where in the statement it is used (table/schema/column name vs. literal
in a WHERE clause). This is overkill IMHO as well as connection/cursor
and execute/fetchXXX 'overabstractions'. It may be very misleading sometimes
(especially execute/fetchXXX).

Mikhail Terekhov

More information about the DB-SIG mailing list