Hello,
I tend to agree that allowing to escape non-literals is a really bad idea.
This is certainly not how most underlaying database APIs work - they provide
their own methods for statement preparation and variable binding, in fact
they use different syntax for variable binding into SQL (hence different
DBAPI modules use different ways to pass the arguments - tuple, dictionary
etc). And they all follow rule that only literals can be bound, not table,
procedure, package, view or whatever names. Of course there are some dumb
database backends which do not do variable substition themselves... but who
cares about those anyway :)
If the dynamic statements are real issue for you, it is possible to write
wrapper which takes care of this, but I dont think that is really worth the
trouble as you can simply write something like:
Cursor.execute("SELECT something FROM %(tablename)s WHERE
somethingelse=%%(whoami)s" %
{"tablename":"sometable"},{"whoami":"cookiemonster"})
On other hand the difference between how different DBAPI modules handle bind
variables is indeed quite annoying, it prevents abstraction of the query
code from underlaying database, but only solution which comes to my mind
would be adding "Pythonized parameter style" support for each database
module which would convert Python style to whatever underlaying database
actually works with, for example for Oracle it would do:
"SELECT something FROM somewhere WHERE
somethingelse=%(somethingelse)s",{"somethingelse":"huh"}
---- super duper argument mangler ---->
"SELECT something FROM somewhere WHERE somethingelse=:1",["huh"]
However actually implementing this would be no simple matter - bind variable
processing goes much deeper than simple string mangling I am afraid, SQL
lexical parser would be required for this sort of translation...
Jekabs
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
