[DB-SIG] paramstyle specification
mal at egenix.com
Thu May 23 17:47:12 CEST 2013
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
> 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.
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
More information about the DB-SIG