Re: proposal: PL/Pythonu - function ereport

Поиск
Список
Период
Сортировка
От Catalin Iacob
Тема Re: proposal: PL/Pythonu - function ereport
Дата
Msg-id CAHg_5gq3rvRRneJCMWbHRWThttFm_57KXh-AcRdZbwv4q+mPDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: PL/Pythonu - function ereport  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: PL/Pythonu - function ereport  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: snapshot too old, configured by time
Следующее
От: Greg Stark
Дата:
Сообщение: Re: [RFC] overflow checks optimized away