[DB-SIG] PEP249 - Proposed change to DB-API 2.0

Greg Stein gstein@lyra.org
Fri, 27 Apr 2001 13:22:52 -0700


On Fri, Apr 27, 2001 at 01:24:53PM +0200, M.-A. Lemburg wrote:
> Harri Pasanen wrote:
> > [Making the DB API interface handle multiple paramstyles]
> > 
> > How about specifying a single 'python meta' -style.  So the module
> > writers would support the database native format, and the Python DB-Api
> > format, from which a conversion to native format would exist.  I spent
> > maybe 2 minutes thinking about it, so maybe this is not feasible, just a
> > thought...
> 
> This is not necessarily efficient, e.g. MySQL and Postgresql are
> just fine with wrapping data up in the SQL statement itself,
> but e.g. many ODBC drivers pass in data using column binding and
> only parse the SQL once (parsing and checking for correctness
> takes a long time...) !
> 
> I'd rather leave it at the current open state of affairs. People who
> want to use a generic interface can use wrappers or Chris' dbhelper.py
> module if they want to.


Normally, I like to jump in on these discussions and chatter on about the
API, its view of the world, and how it helps authors and users, and ...

But damn. Marc-Andre has said everything exactly as I would. I've got
nothing more to add! Dang :-)

[ hmm. maybe I've hounded M-A enough over the past five years, that I've
  brainwashed him? :-) ]


I support the suggestion that a DBAPI module can *optionally*: advertise
multiple paramstyles, and allow switching the paramstyle "mode". As always,
there should be a way for a module author to ignore this option as too much
hassle for themselves (and punt to an external system). So if PEP-249 is
revamped to make the "add'l paramstyles" optional, then I'd be +1.

The param styles were chosen with the explicit intent that the DBAPI module
would not even touch the strings. The "?" and ":1" and ":name" forms can all
be passed directly to certain SQL engines, along with input bindings.
"Lesser" databases require munging everything into a single SQL string,
which means they have more flexibility on the param style.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/