[DB-SIG] How to handle database warnings ?

[Federico Di Gregorio]

Scavenging the mail folder uncovered Dave Cole's letter:
[snip]
> M> To solve this, I've added a list attribute .messages to both
> M> connection and cursor objects which will hold the error
> M> and warning messages generated by the low-level code in the
> M> order they are generated by the database. Errors will still be 
> M> reported using Python exceptions, but I am planning
> M> to drop the exception mechanism for warnings.

we are about to add the same thing to psycopg. because of the ALLOW_THREADS
problem (see below) we *alredy* save errors and check them (raising an
exception if necessary) before returning from the invoked method. imo,
clearing the wrning/error state before every method invokation is quite
right.

[snip]
> The interesting thing that I noticed was that when I enabled the
> option which releases the global interpreter lock while an API is
> being called, the program segfaulted inside the callback function.  I
> understood this to mean that you must guarantee that the interpreter
> will not be re-entered if you release the global lock.  I did find
> some documentation which seemed to support this conclusion.

this same problem bited us hard. after releasing the global lock (via
the PY_ALLOW_THREADS macro) you should *never* call any Py_ function
that changes the interpreter internal status. so you can't create new
data, call formatting functions or even raise an exception. we solved
this problem by saving the current error in a variable and then checking
for it and raising the exception just before exiting the outermost function,
outside of any ALLOW_THREADS scope. it worked quite well.

my $0.02,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
  Qu'est ce que la folie? Juste un sentiment de liberté si
   fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra