Yes, it is better as an attribute of the exception, since I agree it is not much use until an error occurs. I wasn't sure how to add an attribute to the exception class, so I put it on the connection because it was simpler :)
On 5 May 2012 21:07, Christoph Zwerschke <[email protected]> wrote: > 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
