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
