2016-01-11 20:11 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > 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. >
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 >
