X-Original-To: pgsql-hackers@postgreSQL.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id EB37D476022; Mon, 31 Mar 2003 11:57:15 -0500 (EST) Received: from europa.janwieck.net (h00045a2e4e7c.ne.client2.attbi.com [24.131.181.55]) by postgresql.org (Postfix) with ESMTP id B6075475F1B; Mon, 31 Mar 2003 11:57:14 -0500 (EST) Received: from Yahoo.com (linksys.janwieck.net [192.168.192.1]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id h2VGvBa13201; Mon, 31 Mar 2003 11:57:11 -0500 Message-ID: <3E887361.2AA6BFFE@Yahoo.com> Date: Mon, 31 Mar 2003 11:57:05 -0500 From: Jan Wieck Organization: Home X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Tom Lane Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: Error-message infrastructure: what about location in PL functions? References: <6819.1047919215@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200303/1214 X-Sequence-Number: 37460 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 #