pypgsql -- not preserving transactions ?

[Frank Miles]

In article <mailman.1032151518.3079.python-list at python.org>,
Gerhard =?iso-8859-1?Q?H=E4ring?=  <gerhard.haering at gmx.de> wrote:
>First, I'd recommend to ask questions like this on the pypgsql-user
>mailing list. You'll find the link on  http://pypgsql.sf.net/

Thanks for the recommendation.  I had tried to look at the archives of the
list only to find "page not found".  Nothing pertinent in the FAQ, either.
Still...

>* Frank Miles <fpm at u.washington.edu> [2002-09-16 03:15 +0000]:
>> I've discovered that the 2.0 version of pyPgSQL packaged with Debian/woody
>> doesn't preserve transactions...
[snip]

>I can't reproduce that behaviour here. What do you do to ignore the
>PgSQL.OperationalError? Or is it a different exception that gets thrown?

Yes, that exception gets thrown.  Perhaps this simply reveals a gap in my
understanding -- I thought that it was Postgres that was handling the
transactions.  Presuming that the cursor wasn't starting a new transaction,
even if the dumb user used a try/except block to bypass the exception (and
continue with succeeding INSERT attempts), shouldn't Postgres prevent those
later INSERTs?

[snip]

>This area of code hasn't changed up to 2.2, IIRC. Could you provide a
>test case with a minimal schema, minimal code and the output of your
>code. To see which SQL commands pyPgSQL sends, you can simply access
>pyconn.conn.toggleShowQuery, where pyconn is your DB-API connection
>object. This output would be useful, too. Also, which PostgreSQL server
>version are you using?
>
>-- Gerhard

Sure, I've got some simple test code.  But at this point I'm now thinking
that this is more likely a difference in conception -- what _should_
pypgsql do?  Should the application have to track if/when exceptions occur?
It's probably more efficient, though ISTM less clean to do it this way.

Thanks for your reply, Gerhard.  Can you (or someone else) confirm that the
"error" is a difference in conception?

	-frank
--