On 1/21/16 4:57 PM, Pavel Stehule wrote:
> It is not correct - outside PLPython you got a Error (PostgreSQL error
> has not any classes), and isn't important the raising class (Error or
> SPIError). Inside PL/Python you will got SPIError or successors (based
> on SQLcode).
Right. The closest thing we have to error classes is SQLSTATE. If
someone found a clever way to setup an exception inheritance tree[1] on
that then maybe different exceptions would make sense. Short of that, I
don't see it.
[1] There's a hierarchy to the SQL state codes, based on the first 2
characters. So if there was...
class connection_exception(spi_exception) __init__ str = 'Connection Exception'
class connection_does_not_exist(connection_exception) __init__ str = 'Connection Does Not Exist"
...
to map to the small set of errors below, maybe that would make sense.
Obviously that would need to be auto-generated. It seems more trouble
than it's worth though.
Section: Class 08 - Connection Exception
08000 E ERRCODE_CONNECTION_EXCEPTION connection_exception
08003 E ERRCODE_CONNECTION_DOES_NOT_EXIST connection_does_not_exist
08006 E ERRCODE_CONNECTION_FAILURE connection_failure
08001 E ERRCODE_SQLCLIENT_UNABLE_TO_ESTABLISH_SQLCONNECTION sqlclient_unable_to_establish_sqlconnection
08004 E ERRCODE_SQLSERVER_REJECTED_ESTABLISHMENT_OF_SQLCONNECTION
sqlserver_rejected_establishment_of_sqlconnection
08007 E ERRCODE_TRANSACTION_RESOLUTION_UNKNOWN transaction_resolution_unknown
08P01 E ERRCODE_PROTOCOL_VIOLATION protocol_violation
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
