On Mon, 2006-11-13 at 11:28 -0500, Art Protin wrote: > I just looked at Martin's suggestions and I find some theoretical > problems. I had been left with the impression that the "operation" > given as an argument to the .execute() method was SQL but on rereading > the specification (PEP 249) I do not find that made explicit. If it > were explicitly required to be SQL, then I would turn to a text like > "A Guide to THE SQL STANDARD", Fourth Edition, by C.J.Date with Hugh > Darwen and quote from section 20.3, "STATEMENT PREPARATION AND > EXECUTION", in the subsection on "Placeholders": > > Placeholders (i.e., question marks) are permitted only where > literals are permitted. > Note in particular, therefore, that they cannot be used to represent > names (of tables, > columns, etc.). ... > > The DBMS I am coding for requires all table names and column names be > explicit in the query before it can begin to process it, where as the > "proper" placeholders in query are never really filled in, the query > picks up the values to use at execution time. This would require > distinctly different treatment of the two placeholders in query like: > > select Name from ? where City = ? > > (and I dread having to parse the SQL in the interface to distinguish > between these two).
You're correct, the description of the execute method does not specify that the operation be an SQL query. However, other sections of the PEP do explicitly mention SQL, so it's clear that that's the intent. You don't have to worry about catering to people wanting to use parameter passing to fill in table names. The fact that this works in some DB-API implementations is an unfortunate side-effect of resorting to string formatting due to the lack of a parameter passing API in the underlying database. This behavior is by no means required, and IMHO not desired. Hope this helps, Carsten _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig