[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)
Vernon D. Cole
vernondcole at gmail.com
Sun May 19 18:10:17 CEST 2013
I am a bit confused. Two posts ago you said that supporting other
parmamstyle values would be "*way, way* more complicated". Now you say: "
qmark or not qmark syntax is a non-issue: converting across types is a
Clearly you are against the "two paramstyles are mandatory, others are
optional" rule. But I cannot quite make out whether you are against
implementing it because it is too hard, or because it is too easy.
My own experience, as a developer who has already done this, is that the
job is somewhere in the middle -- somewhat complex. It took me a day or
two to write the code and the tests. Not a job to give a beginner, but not
a real head breaker either.
You also state that the modification is not needed because it has never
been requested by one of *your* users.
<<Please avert your eyes while I remove my Windows-driver-developer shirt
and put on my Linux-django-developer shirt>>
I am a software engineer who is developing a system to aid in the
eradication of polio from the earth. Our company uses django, and
PostgreSQL databases on Ubuntu servers and workstations, using psycopg2.
We now have a need to interface our data with SQL Server databases and
analysis tools used by other agencies. In order to do so, I am updating a
db-api driver I maintained when I worked for a Microsoft-only shop, and
have begun working with the core developers of django to better
inter-operate with SQL Server.
A discussion on the subject of 'format' paramstyle with my mentors on the
django-developers group revealed that they do _not_ favor the style, and in
fact it causes problems by its interaction with the Python '%' operator.
They would welcome the opportunity to simply their lives by gradually
moving to 'qmark' and 'named' styles, which do not suffer from '%'
Please use your time and influence to make this possible for our premier
database system. Will this method of communication be sufficient, or
should I open a trouble ticket addressing the issue?
Your sincere user,
Now, you have had a user request.
Please don't just take your ball and go home. That will not stop the ball
game, but it will rain on it. Work with us.
On Sat, May 18, 2013 at 8:22 PM, Daniele Varrazzo <
daniele.varrazzo at gmail.com> wrote:
> On Sat, May 18, 2013 at 9:29 AM, Vernon D. Cole <vernondcole at gmail.com>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG