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