[DB-SIG] Towards a single parameter style

[Matthew T. Kromer]

Kevin Jacobs wrote:

>Do you mean something like ''' WHERE FOO=?AND"BAR"=?OR't' '''?  It should be
>valid under the SQL92/99 tokenizing rules, though that says nothing about
>what vendors have implemented.
>  
>

Yes, its very FORTRAN-esque and hideous, but legal.  Personally, I'd 
solve it by not solving it, e.g. the equivalent of a smart_split(string) 
which broke around unquoted ? (and never returned them) and then let the 
driver glue in whatever it wanted.

>Here is another case: several RDMS allow runtime configurable SQL syntax
>specification.  What happens when the dialect is changed at runtime, and
>requires your tokenizer to know which mode is active?  What happens to
>systems where these settings are local to the given active transaction and
>the transaction is committed via pass-through SQL and the dialect reverts to
>the default connection dialect?
>  
>

Well your focus is slightly different than mine.  I know fairly 
specifically what the target of the transform is, so I dont need to 
 concern myself how to handle someone else's cases.  

I find the most aggravating construct in the Python DB API to be the 
lack of any ability for the adapter and the program to negotiate over 
features -- the adapter says "this is the one thing I support" and 
that's that.  In reality, I could support 3 or so different parameter 
notations without any difficulty whatsoever, and if I had to build a C 
string parser to handle question marks, I could just as easily extend it 
to handle the other string formatting conventions as well.   Likewise, 
if I could negotiate "extended argument formats" I could raise an error 
when a method was invoked with a call signature that was not DB API 2.0 
strictly compliant.

Here's to wishing Driver.paramstyle was a tuple, rather than a string.

I also have some noodling to do over when to end-of-life support for 
older Python versions.  I think I have one or two python 2.1-isms in 
DCOracle2 by now -- I haven't checked it recently (there is some REALLY 
crufty stuff in the python layer code, and its a mental blind spot).

I don't recall if PythonLabs has tried to make some kind of end of 
life/support announcement for older Python versions or not.  It is a 
complete PAIN IN THE ASS for me to build platform * version different 
binary builds whenever I want to make a release.  I currently build 
Python 1.5.2, Python 2.1.3 and Python 2.2.2 binaries on Windows, Linux, 
and Solaris all against Oracle 8i libraries.  If I also built against 
Oracle 9 I'd go bezerk (not that anyone would notice).