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. # #================================================== [EMAIL PROTECTED] # ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
