2012/12/28 Peter Geoghegan <pe...@2ndquadrant.com>: > 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 >
for this subject ANSI SQL is more relevant source or manual for DB2 or Oracle. Design of Python and native PL languages are different. Python can use complex nested structures. PL - PL/pgSQL or PL/PSM is designed for work with simply scalar types. So these environments are not comparable. > 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. yes, it is not valid argument, I am sorry. Lot of error fields doesn't work if developer doesn't respect some coding standards. It is not just routine_name. Only when your implementation is correct, then code works. Best regards Pavel > > -- > 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
