Re: proposal: PL/Pythonu - function ereport

Hi

>
> > I though about it lot of, and I see a the core of problems in orthogonal
> > constructed exceptions in Python and Postgres. We working with statements
> > elog, ereport, RAISE EXCEPTION - and these statements are much more like
> > templates - can generate any possible exception. Python is based on
> working
> > with instances of predefined exceptions. And it is core of problem.
> > Template like class cannot be ancestor of instance oriented classes. This
> > is task for somebody who knows well OOP and meta OOP in Python - total
>
> I've been following this discussion with great interest, because PL/Java
> also is rather overdue for tackling the same issues: it has some partial
> ability to catch things from PostgreSQL and even examine them in proper
> detail, but very limited ability to throw things as information-rich as
> is possible from C with ereport. And that work is not as far along as
> you are with PL/Python, there is just a preliminary design/discussion
> wiki document at
> https://github.com/tada/pljava/wiki/Thoughts-on-logging
>
> I was unaware of this project in PL/Pythonu when I began it, then added
> the reference when I saw this discussion.
>
>
I read your article and it is exactly same situation.

It is conflict between procedural (PostgreSQL) and OOP (Python, Java) API.
I see possible solution in design independent class hierarchies - static
(buildin exceptions) and dynamic (custom exceptions). It cannot be mixed,
but there can be some abstract ancestor. Second solution is defensive -
using procedural API for custom exceptions - what i doing in PLPythonu.

Regards

Pavel