On Sunday 12 August 2007 19:07, Mike Meyer wrote: > > How is "We only recognize parameter markers where we recognize > parameter markers" *not* circular?
The SQL specifications dictate where parameter markers can be used. Please search for "SQL-92" and examine the specifications document for further details. It should be noted that what I have proposed previously is merely the introduction of the standard parameter marker as adopted by other major standards such as ODBC and JDBC. [...] > I think you just pinpointed the problem: parameter substitution in > dbapi is being advertised as the solution to a problem it's not really > adequate to solve. IIUC, it's restricted by the underlying SQL > implementation (and inherits portability problems from there as > well). That some underlying SQL implementations may not support it at > all further complicates things. PEP 249 (DB-API 2.0) refers to binding parameter values, not substituting values into the query, even if the latter does happen with some systems (after some modification of the values). So, no-one is really advertising parameters in the way you've described. [...] I agree that for some kinds of applications, there's a need for improved query building tools, especially for those of us who don't really see the attraction of object-relational mapping technology. Meanwhile, we still need a better way of dealing with parameters. Having a database module tell me at runtime that its paramstyle is "xyz" is not particularly useful if I've already written my queries, and having lots of different modules with different paramstyles makes for a tedious exercise in providing queries for them all. And the pyformat style is just an anachronism providing a false convenience for the dubious benefit of module writers. Paul _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
