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