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

[Vernon D. Cole]

Dear Daniele:

  I spent some time this morning considering your long and well presented
appeal.  At my age, I have to walk, rather than run, for exercise, and it
helps give me a lot of time to think.

I have experience in a small, monolithic shop like the one you hypothesize
in your example.  I say "small", but that is a relative term -- it was the
corporate data center for Georgia Pacific, at that time (around 1980)
number 52 on the Fortune 500 list. G.P. had, I think wisely, decided _not_
to upgrade to the latest fad, interactive mainframes, and kept their 1968
era IBM 360/65 well maintained, and doing what it does very well: high
speed batch processing.  Where they needed to be interactive, they decided
to go with another solution: Digital Equipment minicomputers. (That's why
they hired me.)  They saved millions of dollars by sticking with that
venerable model 65 and its OS-360 operating system.  But the day finally
came when they had to roll an IBM 370 into the shop and go interactive,
running CICS on OS/MVS. It was, as you suggested, a _very_ painful period
for that shop.

Painful, but inevitable.  I hope that I may have made that transition
easier by providing some tools to smooth things out.

CICS is a resource hogging badly performing dog. Our little $100,000
PDP-11/70 would run circles around the $3,000,000 370. I could tell
stories... Similarly, MS SQL Server is plainly inferior to PostgreSQL.
Thursday, I ran my first django test suite on SQL Server. It took _six_
_hours_. (On my Postgres server it took 42 minutes.) Why would anyone pay
actual money for such a monster??  But thousands of people do, and I must
interact with them.

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'.   (I think that is fair, since I have already taken
the time to make _my_ database driver support the format you prefer. It
added 65 lines to my Python code to support both new formats.) Then,
someday in the future, some fortunate person will be able to say: "let's
get rid of this pig SQL Server and run our stuff on Postgres" and it will
be within the financial realm of possibility for them to do that, all
because you invested that time.

Meanwhile, the people in your neat little monolithic shop will add one line
of code the their programs, telling your database driver to go ahead and do
things the old (efficient) way.  The fact that they will also be enabled to
sneak up on inevitable pain rather than being blind-sided by it is a plus.

At least, that's what I think.
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20130518/f6a85f5c/attachment-0001.html>