Re: proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement

From: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement
Date: 2013-06-24 09:15:30
Message-ID: CAGPqQf24JMba0df5buaVica0SkTJxWEePJDEarhEPrF8M3MQfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Use of this feature is to get call stack for debugging without raising
exception. This definitely seems very useful.

Here are my comments about the submitted patch:

Patch gets applied cleanly (there are couple of white space warning but
that's
into test case file). make and make install too went smooth. make check
was smooth too. Did some manual testing about feature and its went smooth.

However would like to share couple of points:

1) I noticed that you did the initialization of edata manually, just
wondering
can't we directly use CopyErrorData() which will do that job ?

I found that inside CopyErrorData() there is Assert:

Assert(CurrentMemoryContext != ErrorContext);

And in the patch we are setting using ErrorContext as short living context,
is
it the reason of not using CopyErrorData() ?

2) To reset stack to empty, FlushErrorState() can be used.

3) I was think about the usability of the feature and wondering how about if
we add some header to the stack, so user can differentiate between STACK and
normal NOTICE message ?

Something like:

postgres=# select outer_outer_func(10);
NOTICE: ----- Call Stack -----
PL/pgSQL function inner_func(integer) line 4 at GET DIAGNOSTICS
PL/pgSQL function outer_func(integer) line 3 at RETURN
PL/pgSQL function outer_outer_func(integer) line 3 at RETURN
CONTEXT: PL/pgSQL function outer_func(integer) line 3 at RETURN
PL/pgSQL function outer_outer_func(integer) line 3 at RETURN
outer_outer_func
------------------
20
(1 row)

I worked on point 2) and 3) and PFA patch for reference.

Thanks,
Rushabh

On Sat, Feb 2, 2013 at 2:53 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:

> Hello
>
> I propose enhancing GET DIAGNOSTICS statement about new field
> PG_CONTEXT. It is similar to GET STACKED DIAGNOSTICS'
> PG_EXCEPTION_CONTEXT.
>
> Motivation for this proposal is possibility to get call stack for
> debugging without raising exception.
>
> This code is based on cleaned code from Orafce, where is used four
> years without any error reports.
>
> CREATE OR REPLACE FUNCTION public."inner"(integer)
> RETURNS integer
> LANGUAGE plpgsql
> AS $function$
> declare _context text;
> begin
> get diagnostics _context = pg_context;
> raise notice '***%***', _context;
> return 2 * $1;
> end;
> $function$
>
> postgres=# select outer_outer(10);
> NOTICE: ***PL/pgSQL function "inner"(integer) line 4 at GET DIAGNOSTICS
> PL/pgSQL function "outer"(integer) line 3 at RETURN
> PL/pgSQL function outer_outer(integer) line 3 at RETURN***
> CONTEXT: PL/pgSQL function "outer"(integer) line 3 at RETURN
> PL/pgSQL function outer_outer(integer) line 3 at RETURN
> outer_outer
> ─────────────
> 20
> (1 row)
>
> Ideas, comments?
>
> Regards
>
> Pavel Stehule
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
Rushabh Lathia

Attachment Content-Type Size
get_diagnostics_context_initial_v2.patch application/octet-stream 8.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-06-24 09:21:22 Re: COPY and Volatile default expressions
Previous Message Cédric Villemain 2013-06-24 08:20:03 Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT