[DB-SIG] Towards a single parameter style

Matthew T. Kromer matt@zope.com
Mon, 17 Feb 2003 14:25:01 -0500


Kevin Jacobs wrote:

>On Mon, 17 Feb 2003, Anthony Tuininga wrote:
>  
>
>>Since you seem to have experience in this matter, I'll ask you.... :-)
>>
>>I take it that simply parsing for ? (or whatever is equivalent for the
>>different styles) and igorning quoting is insufficient? Could you give
>>some examples?
>>    
>>

Correct me if I'm wrong -- I dont use qmark notation ;)  but I count 
only 5 bindings here:

>Here is a "simple" example:
>
>  SELECT cost AS "?"
>  FROM   sales
>  WHERE  quantity  > CAST(? AS double precision)
>
	
	One


>    AND  shipdate  < ?::DATE
>  
>

    Two

>    AND  "shipped ?" IS NOT NULL
>    AND  comment NOT LIKE ? | '?'
>

    Three


>    AND  descr = '\'?\''
>    AND  orderdate NOT BETWEEN ? - INTERVAL '2 days' AND ?;
>

    Four and Five

>
>It is not intrinsically hard to parse out the parameters from the above
>statement, but it is hard to see how it can be done without significant
>performance penalty.  And this is a relatively simple example -- there are
>many other corner cases to consider (e.g., nested queries, literal escaping
>variations, runtime configurable SQL dialect support, etc..etc..etc...).
>
>-Kevin
>
>  
>
I'm fairly sure the RDBMS names don't get substituted into, e.g. 
"shipped ?" and I'm confident that string literals don't.

I'm also not sure how valid ?::DATE is -- I've never seen that before so 
I'm not sure what SQL dialect it is (could be my ignorance, too).

In any case, I would contend that MOST drivers tell the adapter what 
Python says the type is for bound arguments, and let the database do 
type conversion.

I could rip off a C based string parser that handled the quoted vs. 
unquoted characters with reasonable speed such that I could convert ? ? 
? into :1 :2 :3 or whatever in reasonable time.  (And :2::DATE is 
probably just as valid or invalid as ?::DATE <grin>)

A better question is if there are tighter rules to follow, e.g. 
<alphanumeric>?<alphanumeric>  being non-quoted ie WHERE FOO =?a -- 
ignore it or not?  I dont think I've ever seen a full lexer for this (a 
parser is irrelevant, so long as it can be tokenized).  The deal for me 
as a driver author is to be able to do string conversion on the SQL 
statement to a format that the underlying RDBMS supports; I let the 
RDBMS raise an error if it doesnt like a parameter rather than trying to 
out guess it.  Of secondary importance is to not use Python itself to do 
the string conversion, since Python is very slow at character-at-a-time 
operations.

An unrelated quibble has to do with how to cope with instances that are 
passed as binding variables.  I have DCOracle2 puke on them rather than 
attempt to string-ify them and bind the string equivalent (except in one 
special case ;)  This has never been an issue, so I'm not worried about 
it, but it would be easy enough to do.