Peter, I'm just reviewing your SQLSTATE patch.
It works nicely with both the classic API and the DB-API 2.
But I wonder whether making it a property of the connection is the right
approach.
In DB-API 2 we could make it a property of the cursor instead, and
instead of storing the last sqlstate after every sql command, we can
just retrieve it from the last_result of the corresponding
pgsourceobject when requested as a property of the cursor.
In the classic API, we could make it a property of the query object, but
the problem here is that no query object is returned in case of an
error, so this is not really useful.
A simple solution to this problem would be to add sqlstate as an
attribute to the exception raised when an error is raised.
This is also the way how SQLSTATE is returned in psycopg2 and some other
drivers. I only wonder why the call the attribute "pgcode" instead of
"sqlstate", since SQLSTATE is meant to be a database independent string,
so it would make sense that all DB-API 2 drivers use the same name for it.
Opinions about making sqlstate an attribute of the exception raised?
If we implement it that way, then we might not even need to add it as a
property to the connection (resp. the cursor or query object), because
SQLSTATE is only really interesting in the error case. Theoretically you
can get warnings in the 01... or 02... class without an error, but they
are not very interesting and I was not able to provoke such.
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo.cgi/pygresql
