[Zope] best postgreSQL adapter?

[Federico Di Gregorio]

Scavenging the mail folder uncovered ender's letter:
> >>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.
> 
> incidentally, my attempts at 'heavy use' were for some tenative work i was 
> doing on a postgres storage, but i ended up having too many problems getting 
> any of the postgres adaptors to properly handle binary data (not in lob in a 
> text field), bind variables, and calling of procs (converted over the 
> OracleStorage to pl/pgsql procs) all at the same time. between the fact that 
> a db -backed storage wasn't very useful in the first place and the difficulty 
> in getting things working i shelved it.

psycopg should have no problems with binary data in a string. is uses *only*
python strings, that are 8-bits clean and can also contain \0. as i said
we still don't support callproc() but you can always execute("SELECT proc()")
and fetch the results...

> i was wondering if there are any plans for psycopg to go beyond the db-api 
> and support more of the functionality of libpq, such as asynch requests, and 
> notifications. (yes, i know the line about contributions, but i'm more 
> curious about your plans for psycopg).

async requests are imho, a must. we'll begin to add extra stuff after 1.0.
goals for 1.0 are *complete* DBAPI compliance (plus some little extensions,
like cursor commits and the type system) and stability. after that we'll
start working on an extended api to support some of the stuff in libpq.

> >>> one thing to not about ZPygre is that it synchronizes all db access. if
> >>
> >>this is bad, because you can't rollback...
> 
> ok, i'll bite. why not?

by "synchronizes" i intended that it works in "autocommit", i.e., does not
do a BEGIN for you. that way every execute() is automatically commited to
the db and you can't rollback. pretty bad in zope, where one of the niciest
things is the server doing a rollback (if i read the code right) when an
error occurs in the current page. 

> >>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.
> 
> hmmm... i vaguely recall someone posting some comparisions between pygre and 
> popy in the last month or two, you'll have to check the searchable archives.

ok. i'll go searching...

> >>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!
> 
> true, i'll try my attempts on a postgres storage on it and see what happens. 
> although for something like a zodb storage the multiple connection thing is 
> not useful since the zodb will synchronize access to the storage layer.
> 
> i'll see if i can convert my experiments into some unittests.

very nice. please report any problems and ask for  features if you need
particular ones. real-cases are always the best tests for software like
drivers.

thank you for your comment,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
                           Don't dream it. Be it. -- Dr. Frank'n'further