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

[M.-A. Lemburg]

Chris Cogdon wrote:
> 
> On Fri, 27 Apr 2001, M.-A. Lemburg wrote:
> 
> > That's easy for you to say ;-) However, your small benefit will cost a
> > lot of module writers a lot of work and sometimes it may even
> > not be possible getting this right.
> >
> > To support all the different styles, the module writer would have
> > to parse the SQL statement to figure out how to map the paramstyle
> > used in there to the native one. Writing an SQL parser is not
> > necessarily possible though, since there are so many different
> > SQL variations in use out there. I'm not even talking about quoting
> > rules here ;-)
> >
> > If you really care about being able to change database interfaces,
> > then you'll have to write an abstraction for your interface anyway,
> > so why put the burden on the DB API writer here ? (This only makes
> > it harder for interface writers to come up with code which can
> > be considered DB API compatible.)
> 
> Okay... that could be a fair statement... lets analyse it:
> 
> The difference between format and pyformat is really python specific. I
> dont know of any C DB-API's that accept python style formatting... in at
> least that case, and many other DBs where 'format' is used, python is used
> to turn the query and all the arguments into a single string, escaping
> each of the argument types appropriately.
> 
> Just looking at format and pyformat, I'd hate to have to write a wrapper
> function just because some Python API writer chose pyformat rather than
> format.... I /like/ the ability to specify my arguments positionally,
> rather than having to wrap them up in a dictionary.
> 
> A wrapper in this case is very difficult, too, since I'd have to parse the
> query for the %s's, then turn them into %(somevarN). Not trivial. It would
> be a /lot/ easier for the API writer to have two pieces of code that turn
> a format, and a pyformat, request into the appropriate chunks to pass to
> the C API.
> 
> Of course, this is making a lot of assumptions about what the C API looks
> like. In both Mysql, and Postgresql's case, the API takes a single string.
> So... what's stopping Python API's for those two Databases from supporting
> /all/ the paramstyles?, since they all have to be interpreted one way or
> the other.

You are missing the point here: when talking about changing the
DB API specs you enforce a standard on all DB API conform modules,
not only the ones which could easily implement the change. This is
unacceptable.

Note that the DB API spec opens up the possible parameter format
to *simplify* the task of the module writer -- she can choose
whichever parameter format suits her best.

The proper solution for your wish would be to define a "standard 
extension" to the DB API (we've had this discussion already) which is
then appended to the spec for module writers to use as guideline in case
they want to add this functionality to their modules.

Please write up such an "standard extension" section and post
it to the list.

> I can certainly see wanting to place a restriction on the paramstyle
> supported if the C API actually supported one or the other of the given
> types. But for the above two databases, there's no excuse. The python DB
> team could very well supply a library to assist API writers in this
> regard.

You mean: a library for parsing parameter markers and finding the right
way to quote data ? I doubt that this will be possible since databases
usually have their own view of how to escape data in SQL statements.
Also note that some DBs have restrictions on the overall size of the
SQL statement, which could render this approach useless for e.g.
BLOBs.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/