On 1/11/16 12:46 PM, Pavel Stehule wrote:
2016-01-11 19:41 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com <mailto:jim.na...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
