[DB-SIG] paramstyles, again

Carsten Haese carsten at uniqsys.com
Mon Jun 4 01:08:57 CEST 2007


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. 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. ;)

Best regards,

-- 
Carsten Haese
http://informixdb.sourceforge.net




More information about the DB-SIG mailing list