Re: [Gnumed-devel] vote on postgres interface

[Horst Herb]

On Thursday 08 August 2002 7:19 pm, you wrote:

> Which isn't exactly painful in my experience and actually a
> good thing. We should be using mxDate _anyways_.

What for? I didn't miss and time/date functions yet, all I needed was in the 
Python standard library

> How so ? You are talking pgdb.py, aren't you ? This seemed to
> not even come with the Windows Python (2.1) that I installed
> last night (PyPgSQL saved the day).

I am talking about pg.py - pgdb.py comes as well in the same packet 
(PyGreSQL), yet it depends again on mxDateTime.
If you install cygwin, you'll get it automatically.
PyPgSQL only seemingly saved your day -you'll get a nasty surprise when you 
try to retrieve dates and a few other things.

Alternatives:
pgdb.py - same package as pg.py, but depending on mxDateTime and providing 
DB-API compatibility, thus lacking a few PG specific features (such as BLOBS)

PyGresQL: available in binary form for Linux and Windows, though the Linux 
version seems neglected lately. Slowest adapter so far (?)

PsycoPG: fast, nice features, but a bugger to install on anyhthing but 
Debian. Only sporadic Windows support. 

> If we standardize on one interface why not on "the best
> available" ? I haven't found pgdb to be very type friendly,
> nay, particularly BLOBs are handled less than desirable but
> this may be due to my using Python 2.1 still.

This was exactly my point - I found pg.py so much better than any other 
interface, and I tried the lot now.

> > - better interoperability with postgres specific tools like pgnotify (?)
>
> Haven't been able to see this benefit yet ? I know I want
> notify/listen but haven't seen it supported anywhere.

Then try pgnotify (http://www.post1.com/home/ngps/pgnotify/), it works!
My idea is to run a separate thread listening for backend notifications 
(blocking), which just queues messages with our gmDispatcher.
gmDispatcher needs threadproofing anyway, but this is not much work to do.

I have been hanging around on the DBAPI mailing list for a while - nobody 
seems keen on really establishing a truly portable standard, and none of the 
different Postgres adapter programmers seems keen on agreeing on a common 
standard either, so I though they can get stuffed and we use what's most 
convenient - thought that was pg.py

Horst