[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

[Daniele Varrazzo]

On Sat, May 18, 2013 at 9:29 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> So, here is the thing.  I want you to take the time to make your database
> driver "*way, way* more complicated" by supporting the SQL format I must
> use, which is 'qmark'.

Aaahhh... is it that what you want? If what you wanted is a psycopg
talking qmark, why on the earth haven't you asked for that? Why
instead are you asking the DBAPI to rule that every db driver must
implement qmark?

There: just released qmarkpg, allowing using qmark and named
parameters with psycopg:

 - Source: https://github.com/dvarrazzo/qmarkpg
 - PyPI: https://pypi.python.org/pypi/qmarkpg/

This is not a mock. The module passes the DBAPI test suite (2PC included).

Nobody in my about 10 years of frequentation of the psycopg mailing
list has ever asked psycopg to implement qmark/named. I repeat it:
this is a need nobody has ever expressed. And believe me we have been
asked for a lot of things.

This module is the proof that qmark or not qmark syntax is a
non-issue: converting across types is a trivial operation. Writing a
wrapper module is a solution infinitely superior to any
module/connection/cursor writable attribute dancing; perfectly thread
safe and 100% backward compatible.

My impression from this long thread is that we are in front of
bikeshedding in its purest form: I haven't read a rationale yet to
justify the rewrite of *every query* written in Python against MySQL,
PostgreSQL and god knows what other database server. The justification
has been just a tad more than "we like the ?". The feature
specification is "let's copy Java".

Well, I've looked into that too: JDBC specifies *only* qmark, not
named. Named is only supported by *a different* object (a wrapper, I
understand): JDBC does not define a grammar where both qmark and named
can be used. And unsurprisingly so: the grammar is ambiguous:

cur.execute("select $$a ? and a :foo$$", args)

This is a valid postgres query. If args is an object implementing
Mapping and Sequence ABCs there's no way to disambiguate that. Now go
on and tell me that we could double the ? even when the :foo are used:
we are making up that syntax now, because JDBC hasn't event tried. Oh,
and in the placeholder with unary "?" operator (valid in postgres)
"???": is the operator prefix or suffix?

Any driver implementing both positional and named arguments will face
the ambiguities of a grammar the proponents have not specified: a
problem that format/pyformat don't have.

My bottom line is that it is provable that a spec mandating
qmark/named is broken,  and psycopg will never implement it: not only
for its technical inferiority but above all because there is no real
request for it, and people who believe they need that can obtain the
same result in trivial ways without bothering the rest of the world.

-- Daniele