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.
Error and Fatal exception classes are introduced in my patch - it was Peter' request (if I remember it well), and now I am thinking so it is not good idea.
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.
I have same opinion now. I remove it from my patch.
-- 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
