[DB-SIG] paramstyle specification (was: Two sample implementations of ['named', 'qmark'] auto switch (a report))

[Vernon D. Cole]

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'.

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.

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'

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.

I am going to let Suzy Programmer use 'paramstyle' to say to me: "I would
like to use named parameters at this moment."

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."

I think that is a perfectly legitimate contract.

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.

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.

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.

The list of mandated paramstyles would become three: ['named', 'qmark',
'native'].
'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.

Pardon me if my proofreading failed.  I broke my glasses last night.
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130522/fb44d8ca/attachment.html>