[DB-SIG] paramstyles, again (was: Controlling return types, again)

[Carsten Haese]

On Tue, 2007-05-22 at 09:22 -0400, Art Protin wrote: 
> Initially I also saw the .paramstyle as providing the implementor too
> much freedom.
> 
> However, I chose to take it as a challenge.  In my
> implementation, .paramstyle is not
> read-only but read-write and all of the defined styles are accepted.
> In fact, once I
> figured out how to handle the parsing of SQL comments & literals,
> parsing of any
> style of parameters was almost trivial (I had to do that parsing in
> Python due to the
> nature of our system).  [Actually, I had to add code to block the
> styles "pyformat" 
> and "format" because my boss agreed with Carsten, although he would
> have preferred
> that I removed code.]
> 
> In my opinion (which is never as humble as it should be), "qmark" is
> barely adequate;
> numeric should be the required minimum.  But now that so many have
> gotten used
> to "qmark", it will probably never go away.
> 
> I am glad that the spec. [PEP 249] did not require that .paramstyle be
> read-only and
> now oppose any attempt to "correct" that oversight.

Making the module's paramstyle writable is an odd approach. If you have
one function that needs one style and another function that needs
another, each function will have to explicitly set the module-level
paramstyle attribute before executing the query, for fear that another
function might have changed it in the meantime. That faint screaming you
hear in the distance is thread-safety being thrown out the window.

As an example of an alternative, InformixDB allows qmark, numeric, and
named parameters, and execute() recognizes on the fly which one you're
using. The paramstyle attribute only "advertises" numeric, because there
is no way to advertise all supported styles while remaining compliant
with the spec.

qmark may not be adequate in your opinion, but it has the advantage that
it's SQL standard, as far as I know. Hence, it's the parameter style
that's most likely to be a native parameter style in commercial SQL
implementations. If we made qmark mandatory, application developers
could rely on the fact that at least qmark style will be supported.
Allowing additional parameter styles, either recognized on the fly by
execute(), or given as a cursor attribute, or given as an optional
argument to execute(), should be encouraged, but not required.

This has been discussed before, but I'd like to re-cast a vote on this
for DB-API 3.0:

* Deprecate/disallow pyformat/format paramstyles.

* Make qmark the mandatory minimum paramstyle. Allowing additional
parameter styles (numeric and/or named) would be optional and
implementation specific.

Best regards,

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