2012/12/11 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> /* if we are doing RAISE, don't report its location */ >> if (estate->err_text == raise_skip_msg) >> return; > >> It is some what we want? > > My recollection is that that special case was added because people > complained about the "noise" from location lines otherwise: there are > too many applications using RAISE to report user errors, for which a > traceback would just be useless noise. I dug around in the archives a > bit but couldn't find the original discussion. But I did find a fairly > recent complaint that it's still too noisy (rather than not noisy > enough): > http://archives.postgresql.org/pgsql-hackers/2011-10/msg00838.php > > At the end of that thread we discussed adding a RAISE option to control > the behavior, but nothing's been done about it.
I can understand to this idea - but it don't work yet, respective it working only for one level of call. If you get exception from nested call, then you get CONTEXT from custom exception too: Some flag of RAISE statement can be solution, but I don't like it. Probably you would to change behave for all RAISE statements in function - not individually for one or second. And when you debug some application, you probably invite any solution that ensure change without necessity to modify function's source code. I know so GUC are limited, but in this cases, it has a minimal impact to data - and it can be ajusted on database, session, function level. A analogy is our solution for SQL identifiers and plpgsql variables solving collisions - it is best, and I newer heard about any issue. Regards Pavel Stehule > > regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
