if you're going to be connect to postgres outside of zope i recommend not using PoPy. Its regularly crashes python for me when i try to do things any heavy db work from outside zope. heavy constituting using bind variables, stored procs, checking rowcount, description, etc. in accessing postgres external to zope i'd recommend using pygresql (the native non-standard interface not the dbi wrapper) or pgsql.
while it still does not support direct call of stored procedures using callproc(), psycopg is pretty stable on bind variables and also offers a very nice type-casting system to convers postgres results to custom python types.
one thing to not about ZPygre is that it synchronizes all db access. if
this is bad, because you can't rollback...
you're making lots of small queries this is not the adaptor for you. if you've got some large queries you're better off testing both and seeing which one gives you better throughput (probably PoPy, buts it not a sure thing).
i am very interested in drivers performance: has anybody set up a test of some kind to test this stuff? we use a simple test with 3 threads doing simultaneous INSERTs and SELECTs, creating lots of cursors and psycopg seems pretty fast but i would better like some *real* test.
any others? psycopg mentions that it is designed for heavy multi threaded operations but popy seems more developed.
psycopg has interesting arch, but if you're using postgres its good to keep in mind that libpq (the c client interface to postgres) does not support multiple threads sharing a connection. psycopg does internal bookeeping in
that's why we came out with the "interesting arch" :) note that psycopg does it better when you create lots of short-lived threads all using the same connection and creating one or more cursor each.
the module itself after a connect to keep around a pool of connections. when it matures it should be a very good postgres adaptor for zope.
ok, we wrote it in about 4 weeks, but let me say that psycopg is already pretty stable. we know at least 1 company that switched its production site from another driver (i won't say what) to psycopg because they had stability problems... i am glad to say that the problems are now resolved (mmm... or, maybe, psycopg simply destroyed their entire production server, i can't say... :) jokes apart, a new product can't mature if nobody use it because it is "still young", so try it out and send bug reports, thanx! federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Try the Joy of TeX [http://www.tug.org] -- brought to you by One Line Spam