On May 17, 2013, at 12:36 PM, Daniele Varrazzo <daniele.varra...@gmail.com> wrote:
> What you said before doesn't seem the same: > > On Fri, May 17, 2013 at 2:59 PM, Michael Bayer <mike...@zzzcomputing.com> > wrote: > >> there's no reason a DBAPI can't keep a particular paramstyle, we just want >> to make it so that *all* DBAPIs definitely support "named" and "qmark". The >> rest are just optional. > > You seem suggesting psycopg MUST offer qmark and MAY (at its own > discretion) offer pyformat. No: leaving this choice open is insanely > bad. If dbapi wants to take a position it should mandate one format > with a carefully specified syntax and reject any other formats. > > If a driver wanted to implement support for a different placeholder > syntax (e.g. for query pass-through) it must be do such outside the > dbapi realm and tools like SQLAlchemy can be implemented using the > DBAPI part only, without resorting to driver-specific dialects. yes, you are correct. So please modify my statement to read: "there's no reason a DBAPI can't keep their DBAPI2 implementation available, whatever it does now, and also provide a DBAPI3-compliant adapter via "from <name> import dbapi3". that *only* provides qmark and named via a well-known usage pattern." So I have modified my position of an hour ago to include that DBAPI3 drivers should be entirely in their own module namespace. SQLAlchemy can of course dance around whatever the DBAPI decides to do here, as far as SQLA I'm just trying to push the spec away from ambiguous edge cases such as having to conditionally escape "%" characters based not just on driver but on whether parameters are present. Our issue is more about the new and interesting surprises every single new DBAPI brings us, so to that extent a more consistent and minimal DBAPI spec would hopefully help. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
