Tom Lane wrote:
>
> I thought of something I'd overlooked in my original proposal for error-
> handling upgrades: what about reporting where an error occurs in a PL
> function?
>
> Currently, plpgsql has a hack that prints a separate WARNING giving
> the error location, but this is pretty darn ugly. It should be part of
> the error report message to begin with.
>
> I can see how to create a mechanism that gathers the data (details below
> if you care), but I'm not too sure how it should be reported to the
> client --- ie, what's the protocol message?
>
> This seems nonobvious because (a) the appropriate info might vary
> depending on the PL language involved, and (b) when there are several
> nested PL functions, we probably want to include the whole stack trace.
>
> Here is an example of what you get right now:
>
> regression=# create function foo (int, int) returns int as '
> regression'# begin
> regression'# return $1 / $2;
> regression'# end' language plpgsql;
> CREATE FUNCTION
> regression=# select foo(10,0);
> WARNING: Error occurred while executing PL/pgSQL function foo
> WARNING: line 2 at return
> ERROR: division by zero
> regression=# create function bar (int, int) returns int as '
> regression'# begin
> regression'# return foo($1,$2);
> regression'# end' language plpgsql;
> CREATE FUNCTION
> regression=# select bar(10,0);
> WARNING: Error occurred while executing PL/pgSQL function foo
> WARNING: line 2 at return
> ERROR: division by zero
> regression=#
>
> Note the lack of any info about bar() in the second case --- this seems
> like a bad omission.
>
> I am visualizing some display on the order of
>
> ERROR: division by zero
> WHERE: PL/pgSQL function foo, line 2 at return
> WHERE: PL/pgSQL function bar, line 2 at return
That omission is by me and I did it to lower the confusion a bit. If you
prefer a complete stack backtrace in your log (alas Tcl), I certainly
can live with that.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
