On Tue, 21 May 2013 21:24:19 +0200, M.-A. Lemburg <m...@egenix.com> wrote:
On 21.05.2013 20:55, Michael Bayer wrote:
On May 21, 2013, at 2:30 PM, M.-A. Lemburg <m...@egenix.com> wrote:
Something we do need to address in a paramstyle spec for
qmark and named is SQL comments. Perhaps easiest would be
to disallow them in SQL statements passed to .execute*().
um, meaning no SQL comments allowed in a call to cursor.execute() ? That
would be a really big problem for folks who pass comments in their SQL as a
means to help with database query log parsing. There are definitely folks who
do that, and it's very useful.
Well, I know it's useful, but it also makes parsing SQL for
parameter markers much harder :-)
Oracle uses comments as optimizer hints, i.e. they are required for the
SQL to run.
If we have a parser, it needs to handle comments too. I.e. needs to know
about strings (and skip them intelligently, including the 'It''s Monty
Python' cases) as well as the various comments styles (which again
should be skipped over), example comments styles are:
1. /* C style */
2. -- Microsoft SQL Server style
There may well be others.
PS: mxODBC 3.2 implements both styles and does conversion from
named to qmark. When choosing named style, we explicitly disallow
question marks to appear in the SQL statement to detect errors
early and give proper error messages to the user, rather than
some obscure "too few parameters for statement".
you used the word "underspecified" a moment ago which I found frightening, but
then three paragraphs later it's just the word I need - I think KISS should be the rule
here, the parser is only aware of one paramstyle at a time, and doesn't try to do any
nannying of things that look like other paramstyles.
I'm not sure I understand.
With "underspecified" I meant that we leave the other paramstyles
in the same unspecified state as they are now (or rather leave them
specified by the database module implementations).
For the two main paramstyles we're currently discussing, qmark
and named, we will have to put more effort into specifying
what they mean and how they work.
I agree that adding magic auto-selection of SQL parsers is
not a good idea. If you setup a cursor to expect qmark style,
it should complain loudly when you try to pass in named style
parameters or perhaps even named style SQL.
I think I'm with Michael on this; I would prefer auto selection not be
part of the spec, I also do not want auto detecting (and helper errors)
either, I want to see the (possibly native DBMS) error when it finds
"bad" SQL. If a driver authors wants to add detection logic (Marc-Andre
clearly has customers who want and appreciate this) then the spec
shouldn't disallow it either :-)
I personally would like to see qmark the only required format (with
others allowed), and have (as part of the spec) a reference
implementation that could convert from qmark into X (under a permissive
license) that driver authors could then use and include as part of their
driver if they need it (the ideal would both a pure python and a C based
implementation but I suspect python only would suffice).
Chris
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
