Re: proposal: PL/Pythonu - function ereport

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