Hello
Sometimes I had a problems with identification custom exceptions in
plpgsql, because we skip collecting context
/*
* error context callback to let us supply a call-stack traceback
*/
static void
plpgsql_exec_error_callback(void *arg)
{
PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;
/* if we are doing RAISE, don't report its location */
if (estate->err_text == raise_skip_msg)
return;
if (estate->err_text != NULL)
It is some what we want?
commit f690920a752fa8e59dc9536dd14194b2141163d2
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Thu Apr 24 21:16:45 2003 +0000
Infrastructure for upgraded error reporting mechanism. elog.c is
rewritten and the protocol is changed, but most elog calls are still
elog calls. Also, we need to contemplate mechanisms for controlling
all this functionality --- eg, how much stuff should appear in the
postmaster log? And what API should libpq expose for it?
It is not consistent behave - although I can understand some filtering
for NOTICE level messages. Can we change this behave? Mainly for
ERROR level exceptions.
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
