On Dec 23, 2010, at 3:38 AM, Jan Urbański wrote:
> Oh, didn't know that. I see that it does some more fancy things, like
> defining a inheritance hierarchy for these exceptions and adding some
> more into the mix.
Right, there were some cases that appeared to benefit from larger
buckets than what the existing code classes provided. Also, some of the
exceptions in there are strictly for py-postgresql/client-side things.
> The names I used are not really invented, they're just plpgsql condition
> names from
> http://www.postgresql.org/docs/current/static/errcodes-appendix.html
> with underscores changed to camel case. Also, since they're
> autogenerated from utils/errcodes.h they don't have any hierarchy, they
> just all inherit from SPIError.
For the backend setting, I think this is quite appropriate.
However, for pg-python, I had mixed feelings about this as I wanted to
be able to leverage py-postgresql's hierarchy, but still have the projects
independent. I ended up punting on this one by using a single error class,
and forcing the user to compare the codes. =(
> Sticking "Error" to every one of them will result in things like
> SubstringErrorError, so I'm not really sold on that.
There was some creativity applied to the names in postgresql.exceptions
to accommodate for things like that. (Like no redundant "Error")
> Basically I think
> more PL/Python users will be familiar with condition names as you use
> them in pl/pgsql than with the names from py-postgresql.
I think that's fair assumption. In fact, I think that might make a good
TODO for py-postgresql/pg-python. Provide a plpgsql-code-name to
exception class mapping.
cheers, jwp