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

Поиск
Список
Период
Сортировка
От Rushabh Lathia
Тема Re: proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement
Дата
Msg-id CAGPqQf24JMba0df5buaVica0SkTJxWEePJDEarhEPrF8M3MQfA@mail.gmail.com
обсуждение исходный текст
Ответ на proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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.stehule@gmail.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers




--
Rushabh Lathia
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: COPY and Volatile default expressions