Postgres support

[Paul Boddie]

web2ed at yahoo.com (Edward Wilson) wrote in message news:<5174eed0.0107061058.5446dac9 at posting.google.com>...
> This is exactly what I have been talking about for *years* now.
> 
> Python will only appeal to scientific developers researching the
> "impossible to do" until it handles databases on a first class scale. 
> Oh, and another point, ODBC is dead.  Microsoft has already abandand
> it for OLEDB a COM based library.  References to ODBC need not apply.
> What is needed are RAW Native Drivers at the C/C++ level.

ODBC is not dead as long as anyone is writing middleware which exposes
it.

If I were in the process of writing a Python database module, I'd
rather leave middleware vendors such as Merant and Openlink to the
details of writing "RAW" drivers. At least they have the resources to
track n different releases of n different database system APIs. Then,
I'd just be able to write against the ODBC API.

Alternatively, I'd attempt to find some broadly supported "wire"
standards for database access, although I wouldn't start this exercise
feeling optimistic.

> Python needs a ready to use cross database module which handles
> Oracle, DB2, SQL-Server, Sybase, and Informix.  If it handles Postgres
> and MsSQL that would be a bonus, however, most $$ gigs don't use the
> last two db's much so most of the focus should be on the "big five" or
> at least on the big three (Oracle, DB2, and SQL_Server).

You've certainly been reading your "consultancy house" reports.
However, you don't define what you mean by "cross database". I assert
that it's outside the scope of any Python database framework to ensure
SQL statement independence, for example.

> In my opinion, what has held Python back from going primetime virtical
> is it's lack of commercial grade db support, and I beleive it will
> continue to do so until a tribe of Python-developers gathers to
> accomplish this end.  I have for a long time felt that this has
> warranted the support of the General himself """_GV_""" if for nothing
> else than for moral support and inspiration to see this call to it's
> end.

We have the DB-API, and there are some efforts to address deficiencies
in it - the unification of bind/bound variable syntaxes in statements
is a good start, and some educational materials about their virtues
would not go amiss. We have the DB-SIG with a "tribe" of interested
developers. Time and resources prevent these developers from uniting.

Of course, most developers are motivated to write modules/drivers to
serve their own needs, and I can understand your belief that most of
the not-directly-motivated developers who are looking for projects of
interest tend to become preoccupied with other things less important
to yourself.

> The Python cummunity should throw it's best resources at this void
> until this call is answered.  Once a baseline is established, many
> intermediate developers could mantain such a platform.  The main need
> of the hour is to draw a crowd, once the crowd exists--it will
> self-sustain.

I can see a number of useful things which could be done, some not
solely relevant to the issue of database support:

  * More promotion of "hot projects" on a prominent site, along
    with why they are considered important and how people can
    contribute. As I noted in another thread, it's important to
    include people of all skill levels.

  * Support for the publication of less formal but still PEP-like
    documents for projects and project domains. This should appeal
    to those wanting to make a difference but not necessarily
    wanting to do the work.

  * Consideration of common frameworks for database modules, just
    like the Python graphical user interface API people are
    considering a common GUI framework. Indeed this kind of
    activity could be relevant in other domains.

The last point is worth discussing briefly. I would certainly feel
apprehensive about writing an extension module against a database
system API, but if some people had already written the Python
interface code, requiring me only to concentrate on making the calls
specific to the database system in question, then I might be more
readily persuaded.

Paul