On 1/11/16 12:46 PM, Pavel Stehule wrote:
> 2016-01-11 19:41 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com
> <mailto:Jim.Nasby@bluetreble.com>>:
>
> On 1/11/16 12:33 PM, Pavel Stehule wrote:
>
> 1. break compatibility and SPIError replace by Error
>
>
> At this point I've lost track... what's the incompatibility between
> the two?
>
>
> the name and internal format (but this structure can be visible to user
> space)
Were Error and Fatal ever documented as classes? All I see is "raise
plpy.Error(msg) and raise plpy.Fatal(msg) are equivalent to calling
plpy.error and plpy.fatal, respectively." which doesn't lead me to
believe I should be trapping on those.
It's not clear to me why you'd want to handle error and fatal
differently anyway; an error is an error. Unless fatal isn't supposed to
be trappable? [1] leads me to believe that you shouldn't be able to trap
a FATAL because it's supposed to cause the entire session to abort.
Since spiexceptions and SPIError are the only documented exceptions
classes, I'd say we should stick with those and get rid of the others.
Worst-case, we can have a compatability GUC, but I think plpy.Error and
plpy.Fatal were just poorly thought out.
[1]
http://www.postgresql.org/docs/9.5/static/runtime-config-logging.html#RUNTIME-CONFIG-SEVERITY-LEVELS
--
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
