[DB-SIG] paramstyle specification

[Vernon D. Cole]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130521/2bbc1a53/attachment.html>