[DB-SIG] paramstyle specification

[Chris Clark]

On Tue, 21 May 2013 21:24:19 +0200, M.-A. Lemburg <mal at egenix.com> wrote:
> On 21.05.2013 20:55, Michael Bayer wrote:
>> On May 21, 2013, at 2:30 PM, M.-A. Lemburg <mal at 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