sql escaping module

[Steve Holden]

Fredrik Lundh wrote:
> Frank Millman wrote:
> 
> 
>>Each of the API's includes the capability of passing commands in the
>>form of 'string + parameters' directly into the database. This means
>>that the data values are never embedded into the SQL command at all,
>>and therefore there is no possibility of injection attacks.
> 
> 
> another advantage with parameters is that if you do multiple operations which
> differ only in parameters, the database may skip the SQL compilation and query
> optimization passes.
> 
> 
>>The various API's use different syntaxes for passing the parameters. It
>>would have been nice if the DB-API had specified one method, and left
>>it to the author of each module to transform this into the form
>>required by the underlying API. Unfortunately the DB-API allows a
>>choice of 'paramstyles'. There may be technical reasons for this, but
>>it does make supporting multiple databases awkward.
> 
> 
> agreed.
> 
indeed. I suspect (not having been involved in the decisions) that the 
variations were to minimise the work module implementers had to do to 
get their modules working.

> on the other hand, it shouldn't be that hard to create a function does this mapping
> on the fly, so that drivers can be updated support any paramstyle...  time for a DB
> API 3.0 specification, perhaps ?
> 
It would be a little tricky to convert name-based ("named" and 
"pyformat", requiring a data mapping) parameterizations to positional 
ones ("qmark", "numeric" and "format", requiring a data sequence) and 
vice versa. It's probably a worthwhile effort, though.

> (I'd also like to see a better granularity; the current connection/cursor model is a
> bit limited; a connection/cursor/query/result set model would be nicer, but I guess
> ODBC gets in the way here...)
> 
Yes, it would at least be nice to include some of the more advanced ways 
of presenting query results.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/