[DB-SIG] paramstyles, again

[M.-A. Lemburg]

On 2007-06-04 01:08, Carsten Haese wrote:
> On Sat, 2007-06-02 at 20:42 +0200, Paul Boddie wrote:
>> Carsten Haese wrote:
>>> The same is true for InformixDB. The good news is that making a parser
>>> that locates parameter placeholders is not hard. Essentially it boils
>>> down to "Look for question marks and colons occurring outside of string
>>> literals".
>> I have just written tokenisers using both pyparsing and regular expressions 
>> [1] which split SQL statements into non-literal and literal regions (for 
>> character string literals, of course). I haven't checked using the various 
>> "public" specifications to see if there are any special cases in standard SQL 
>> which would affect this code, but I don't see why we couldn't just have this 
>> sort of thing in all DB-API modules, support question marks as placeholders, 
>> and move the ridiculous paramstyle situation forward.
> 
> As far I can tell, we have already reached consensus for making at least
> qmark mandatory. We also seem to have consensus on at least deprecating,
> possibly even eliminating format/pyformat.
> 
> We still need to settle the question of what to do about numeric and
> named styles. There is some support for making both styles mandatory and
> expecting the API to automatically discern from the query string which
> parameter style is in use.

I don't think that this is such a good idea and I'm also not sure
how you'd do that: what if a programmer mixes the two (or three)
styles by mistake ? How would the programmer test whether a
module supports this automatic detection scheme ?

I'd suggest to make the current module read-only paramstyle
attribute and writable connection/cursor attribute which gets
inherited from connections to cursors.

There's also the problem of parameter type if we allow named
style. The parameters would then have to be dictionaries for
named and tuples for qmark/numeric. So you effectively change
the signature of the .execute() methods based on a parameter
which is not good style.

> This is the most programmer-friendly option,
> and at least InformixDB and sqlite3 already behave this way. (Those two
> I know for sure, there may be more.) Sqlite supports all styles
> natively, and InformixDB uses a simple FSM-based parser to translate
> named and numeric markers into the native qmark style.
> 
> Any input to move this discussion along is appreciated. I'd also like to
> get some more input on the original subject of this thread, type
> mapping. I believe Marc-Andre still owes me a counter-proposal. ;)

Yeah, right :-)

It's not really a counter-proposal, but only a slightly different
approach.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 04 2007)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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