Re: proposal: PL/Pythonu - function ereport

2016-01-11 20:11 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 1/11/16 12:46 PM, Pavel Stehule wrote:
>
>> 2016-01-11 19:41 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com
>> <mailto:Jim(dot)Nasby(at)bluetreble(dot)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.
>

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.

Pavel

>
> [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
>