Re: [Gnumed-devel] vote on postgres interface

[Karsten Hilbert]

> However, this assumption was not quite right.
I am not sure I agree with your reasoning.

> Without any major additional benefit (as the independence from 
> interfaces prooved to be non-existent), it
> - created additional dependency (mxDateTime)
Which isn't exactly painful in my experience and actually a
good thing. We should be using mxDate _anyways_.

> - made the code less readable
Not much so if we "properly" tuck things away in a wrapper.

> - made several statements neccessary where one would be enough
Well, yeah, in a few places.

> Expecting to be flamed, I therefore propose to switch back to the good 
> old "pg" interface as it comes now as standard with postgres
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).

> Benefits:
> - no more dependence on mx (which often creates headaches)
I haven't had any, neither on Linux nor on Windows.

> - easier more intuitive coding
Doesn't seem like that to me.

> - possibly faster code (less type casting neccessary, more "natural" 
>   interface to libpq)
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.

> - 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.

In conclusion: I vote for staying with DB-API unless we have a
compelling reason to switch - which I haven't seen yet.

OTOH, switching will unmistakingly show where we screwed up in
clean design as it will force us to go all over the place.
This might make for better (cleaner) code afterwards if we do
it properly.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346