Re: proposal: PL/Pythonu - function ereport - Mailing list pgsql-hackers

From Catalin Iacob
Subject Re: proposal: PL/Pythonu - function ereport
Date
Msg-id CAHg_5gq3rvRRneJCMWbHRWThttFm_57KXh-AcRdZbwv4q+mPDQ@mail.gmail.com
Whole thread Raw
In response to Re: proposal: PL/Pythonu - function ereport  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: PL/Pythonu - function ereport  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Thu, Dec 3, 2015 at 7:58 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I am sorry, I don't understand. Now due inheritance plpy.Fatal and
> plpy.SPIError has availability to use keyword parameters.

Indeed, I didn't realize this, but I don't think it changes the main argument.

What I think should happen:

1. Error should take keyword arguments
2. same for Fatal
3. Fatal should not be changed to inherit from Error - it should stay
like it is now, just another exception class   You can argue a Fatal error is an Error but these classes already
exist and are independent, changing their relationship is backward
incompatible.
4. SPIError should not be changed at all    It's for errors raised by query execution not user PL/Python code
so doing raise SPIError in PL/Python doesn't make sense.    And again, changing the inheritance relationship of these
existing classes changes meaning of existing code that catches the
exceptions.
5. all the reporting functions: plpy.debug...plpy.fatal functions
should also be changed to allow more arguments than the message and
allow them as keyword arguments    They are Python wrappers for ereport and this would make them
similar in capabilities to the PL/pgSQL RAISE    This will make plpy.error(...) stay equivalent in capabilities
with raise plpy.Error(...), same for fatal and Fatal
6. the docs should move to the "Utility Functions" section    There, it's already described how to raise errors either
viathe
 
exceptions or the utility functions.

I think the above doesn't break anything, doesn't confuse user
exceptions with backend SPIError exceptions, enhances error reporting
features for the PL/Python user to bring them up to par with ereport
and PL/pgSQL RAISE and solve your initial use case at the top of the
thread (but with slightly different spelling to match what already
exists in PL/Python):

"We cannot to raise PostgreSQL exception with setting all possible
fields. I propose new function

plpy.ereport(level, [ message [, detail [, hint [, sqlstate, ... ]]]])"

Is what I mean more clear now? Do you (and others) agree?



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: snapshot too old, configured by time
Next
From: Greg Stark
Date:
Subject: Re: [RFC] overflow checks optimized away