> > 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.
