On 28 December 2012 18:40, Pavel Stehule <pavel.steh...@gmail.com> wrote: > If > I understand you, we have a fields that has behave that you expected - > filename and funcname. And I have not used these fields for > application programming.
No, that's not what I mean. What I mean is that it seems questionable to want to do anything *within* an exception handler on the basis of where an exception was raised from. You should just place exception handlers more carefully instead. Are you aware of any popular programming language that provides this kind of information? Can you tell in a well-principled way what function a Python exception originated from, for example? These are the built-in Python 2 exception classes: http://docs.python.org/2/library/exceptions.html None of the Python built-in exception types have this kind of information available from fields or anything. Now, you might say that Python isn't Postgres, and you'd be right. I'm fairly confident that you'll find no precedent for a routine_name field in any code that is even roughly analogous to the elog infrastructure, though, because acting on the basis of what particular function the exception was raised from seems quite hazardous - it breaks any kind of encapsulation that might have existed. If one person slightly refactors their code, it could break the code of another person who has never even met or talked to the first. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
