Postgres support

Steve Williams stevewilliams at wwc.com
Sun Jul 8 04:07:51 CEST 2001


Alex Martelli wrote:

> "Steve Williams" <stevewilliams at wwc.com> wrote in message
> news:3B4719E1.C5540B19 at wwc.com...
> > Alex Martelli wrote:
> >
> > > "Edward Wilson" <web2ed at yahoo.com> wrote in message
> > > news:5174eed0.0107061058.5446dac9 at posting.google.com...
> > > > This is exactly what I have been talking about for *years* now.
> > > >
> > > A SINGLE module to handle five or more mutually incompatible
> > > interfaces?!  That's utterly ridiculous --
> >
> > Take a deep breath, now.  Calm, calm.
> >
> > I can dream of a paradise with python and wxPython/wxDesigner and a
> > hypothetical pySQL92 universally available, pre-compiled, waiting only to
> be
>
> SQL92 API is _one_ interface, not five, and I suspect that DB2, Informix,
> &c don't support it fully (do they?).
>
> Well, I don't need the *full* SQL92 and I'm not likely to get it.  DB2 7.2
> does talk about SQL92 compatibility, but I'm not willing to explore the claim.

> Interbase has always taken SQL92 seriously, but nobody takes Interbase
> seriously.

Nevertheless, I've managed to survive and prosper on a meager toolkit of
(Select, Insert, Delete, Update, Create, Drop, etc) on SQL-Server, Sybase,
Informix, DB2, and Oracle.  If I'm not fastidious, I can even get by with it in
ACCESS.

So when I say pySQL92, you may take that as something less than the *full*
SQL92.

> > downloaded and installed on more platforms than WinTel.
>
> Assuming I did have a Python API DB 2 implementation, coded against
> the SQL92 API standard, I'm not sure it could even be _compiled_ in a
> single way (doesn't SQL92 define certain preprocessor macro names that
> a compliant API implementation can define differently?) and surely it
> cannot be *prelinked* (against libraries of unknown names...?) in any
> cross-platform way.

[snip]

Some sites provide DB Windows binaries for specific databases:

    http://www.computronix.com/utilities/
    http://home.t-online.de/home/err666/

Some sites provide binaries for non-Windows platforms:

    http://www-frec.bull.com/cgi-bin/list_dir.cgi/download/aix432/

    (No database stuff there, just Python, unfortunately, but I can dream.)

Etc.

A longer list (including my fantasy DB interfaces) similar to the above is what
I had in mind--particularly for those platforms where people are unlikely to
have development capability--the Mac, for example.  But no, I'm not thinking of
a universal, pre-compiled, linked against unknown libraries heap of bits.

If you accept the idea of a limited SQL toolset (for the sake of the argument)
and limit the idea to the big three databases (DB2, Oracle, SQL-Server) and
allow that Postgres and mySQL are already taken care of, I claim the scope of
the effort is not that great.

But here I defer to actual experience.  Man-Yong (Brian) Lee says in

    ftp://people.linuxkorea.co.kr/pub/DB2/

he wrote the initial version of his DB2 API in four days.  His tar file comes to
about 29k bytes.

It certainly seems like it would be less trouble than implementing, say, a
universal threading module.

> [snip]

> > As far as ADO, well, I fear it might be part of a subscription-only
> revenue
> > model in the future.
>
> Perhaps.  So let's start doing XPADO on top of XPCOM just as ADO was
> done on top of COM, shall we?  Technically, for all of its slight faults,
> COM/Automation/OleDb/ADO is a pinnacle of cross-language component
> base infrastructure.  XPCOM has apparently managed to implement a
> faithful-enough rendition of the first (lowest) layer, and PyXPCOM might
> do the same for the second (Automation) -- aren't we almost halfway?-)
>

I found COM (DCOM, actually) hard to deploy.  The code was easy--a joy to write
and use.  The registering and permissions and mystery error messages and
administration and fighting with sysadmins was not.  Maybe it's gotten better.

>
> But most likely the usual crybabies will still be crying about "RAW" (sic)
> C-level interfacing (to a zillion incompatible proprietary idiotic API's, no
> doubt -- the fact that there IS a solid, well-developed standard doesn't
> count:-).  So, naah, not worth the bother.
>

I take no notice of that remark.  Do you have an opinion on Corba?





More information about the Python-list mailing list