[DB-SIG] paramstyle specification

[M.-A. Lemburg]

On 22.05.2013 00:07, Vernon D. Cole wrote:
> I think that we should be careful not to mandate any sophisticated grammar
> processing of the query string. The most notice we should take of comments
> would be to suggest that any reformatting operation might choose to stop at
> a double dash.
>   /* C style */ comments and other non-ANSI-standard standard things should
> not be addressed.  Consider what is the worst that could happen?
> 
>   Let's say a programmer sets my module into 'named' and passes me a query
> with an extra format pattern inside an extended syntax comment:
> 
> SELECT a, b FROM table_c WHERE name = :nam /* :weird */ AND state = :st
> 
> I search for a colon and find one.  Valid names consist of alphanumeric and
> underscore, so I collect characters until I find the end.  I replace the
> whole mess with a question mark, look for 'nam' in my parameter dictionary,
> and place the value in the parameter list I am building.
>   Doing it again, I find 'weird' as the next token.  Two things can happen:
> if 'weird' is in the parameter dictionary, I emit a question mark and add
> the value to the list. If not, then I raise an error.  In the former case,
> the query gets passed to the SQL engine with three parameters for two (that
> it sees) question marks, and it will raise an error.
> 
>   No data is lost or altered.  The programmer will learn not to do that
> again.
> 
>    This is a very different case from performing that same substitution in
> a string literal, where data _does_ get altered.  Even then, I am not going
> to try to find every possible funny literal encoding scheme for every
> possible SQL dialect.  I am only responsible for things between two single
> quotes. ANSI standard.
> 
>   The SQL compiler is the compiler.  I am just running a little macro
> program in front. If running the macro creates syntax errors then the
> compiler lets them know, and they fix it.  The simpler the rules for the
> macro the easier to debug the output.  In particular, if there are no
> parameters, or if the paramstyle is in the native format for my engine, I
> will not look at the command at all.
> 
>   If a module author wants to do more elaborate syntax checking, fine. But
> it should not be included in the standard.

Agreed, but given other comments in this thread, I think we do need
to at least allow standard SQL comments (--) to be used and correctly
parsed by any parameter style converter.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 23 2013)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2013-07-01: EuroPython 2013, Florence, Italy ...           39 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/