Re: proposal: PL/Pythonu - function ereport

Hi

>>> But in my opinion this discussion shouldn't really even be about
>>> catching these things, most of the times you won't catch them and
>>> instead you'll let them go to Postgres. The discussion should be
>>> whether raise plpy.Error(...), plpy.raise_error, plpy.raise_info(,,,)
>>> etc. all with keyword argument support are a good PLPython interface
>>> to Postgres' ereport. I think they are.
>>>
>>
I removed from previous patch all OOP related changes. New patch contains
raise_xxxx functions only. This interface is new generation of previous
functions: info, notice, warning, error with keyword parameters interface.
I didn't changed older functions due keeping compatibility.

I spent lot of time with experiments how to merge PostgreSQL exception
system with Python exception system. But I didn't find a solution without
some design issues. These concepts(s) are too different (note: there are
two concepts: PostgreSQL levels and ANSI SQL SQLSTATE (class, subclass
codes).

I hope so raise_xxxx has benefit for PLPythonu users too. Currently users
has to use ugly workaround to raise rich PostgreSQL exception from Python.
With new function all available functionality related to PostgreSQL
exception can be used simply.

plpy.raise_warning("some doesn't work", detail = "user registration ... ")

This patch is reduced previous patch (no new features, no different
solution, no different code), so I use same entry in commitfest.

Regards

Pavel