On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > On 1/12/16 11:25 AM, Catalin Iacob wrote: >> They're similar but not really the same thing. raise Error and >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is >> raised when coming back after calling into Postgres to execute SQL >> that itself raises an error. Now indeed, that executed SQL raised an >> error itself via another ereport(ERROR, ...) somewhere but that's a >> different thing. > > > Why should they be different? An error is an error. You either want to trap > a specific type of error or you don't. Having two completely different ways > to do the same thing is just confusing.
With my (indeed limited) understanding, I don't agree they're the same thing and I tried to explain above why I think they're quite different. You may not agree. If they are different things, using different exception types is natural.
If I'm writing PL/Python code 1 and I want to raise an error toward SQL code 1 I use raise plpy.Error. plpy.SPIError is what I get if I call into SQL code 2 and that has an error. That error could indeed come from a plpy.Error thrown by PL/Python code 2 or it could come from a SQL syntax error or whatever. But the symmetry holds: plpy.Error is what you raise to stop the query and return errors to your SQL caller and plpy.SPIError is what you get back if you use SPI to execute some other piece of SQL which has an error. I *think* (I'm an internals newbie though so I could be wrong) that SQL code 1 doesn't call into PL/Python code 1 via SPI so why would the latter use something called SPIError to inform the former about an error?
It is not correct - outside PLPython you got a Error (PostgreSQL error has not any classes), and isn't important the raising class (Error or SPIError). Inside PL/Python you will got SPIError or successors (based on SQLcode).
Currently If I raise plpy.Error, then it is immediately trasformed to PostgreSQL, and and then to SPIError and successors.
