<div dir="ltr"><div><div><div><div><div>The major difference -- the change of paradigm (to put it in elegant terms) -- between api 2 and our proposed api 3, is our use of 'paramstyle'.<br><br></div>In api 2, we attempted to use it to tell our client programmer how to talk to us. That did not work out too well.<br>

<br></div>In api 3, we propose to offer the service of letting our client programmer tell us how she wishes to talk, using some construct such as >>>cursr.paramstyle = 'named'<br> <br></div>This method of operation is so different that I wish we could use a different term for it, an actual English word.  Except that I cannot think of one, and I refuse to type "parameter_replacement_variant", so paramstyle it remains, spell checker be damned.<br>

<br></div>I am going to let Suzy Programmer use 'paramstyle' to say to me: "I would like to use named parameters at this moment."  <br><br>To which I am willing to reply: "Okay, encode them as a colon followed by the name.  Please refrain from using that pattern inside of any obscuring structures, since that would foul up my ability to help you."<br>

<br></div>I think that is a perfectly legitimate contract.<br><div><div><br></div><div>But what about the fellow that worries Daniele -- the kind of dweeb who reads language manuals for entertainment and comes up with things like "Hey look!" "If I do _this_ I can make a table named 'single quote'." "Hold my beer while I show you." -- what about him?  As much as we hate it, we all know that guy is out there, and perhaps, sometimes, maybe, might have a legitimate need.<br>

<br></div><div>For that guy, we need a different contract, basically: "Get out of the way and let me do it myself."  So I propose that we offer him that contract.  <br><br>Let's define (sorry) a new paramstyle, and call it 'native'.  (I was first thinking of 'raw', but I like 'native' better.)  That way, the expert (or ID 10 T) user _also_ has a way of expressing his wishes to us.  He would have complete control and the ability to use any obscure features of his SQL dialect he wishes. He does not want or need parameter replacement.<br>

<br></div><div>The list of mandated paramstyles would become three: ['named', 'qmark', 'native'].<br></div><div>'named' and 'qmark' may or may not get parameter replacement processing depending on the needs of the underlying engine. 'native' would always be passed to the engine unaltered.<br>

<br></div><div>Pardon me if my proofreading failed.  I broke my glasses last night.<br>--<br></div><div>Vernon Cole<br><br></div></div></div>