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/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
