Re: Call stacks and RAISE INFO

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Call stacks and RAISE INFO
Дата
Msg-id CAFj8pRALU0VkxWyj2jaAeKjy6zjUVW_z9217mkcaFcSBhVM1fQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Call stacks and RAISE INFO  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2011/10/15 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2011/10/15 Robert Haas <robertmhaas@gmail.com>:
>>> On Sat, Oct 15, 2011 at 12:24 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>> I have no problem with this.  A context can be false for info and true
>>>> for other in default. Please, use a different identifier than
>>>> "context", that can be use for reading context in future - maybe
>>>> "attach_context" or some similar.
>
>>> error_context?
>
>> what about show_context, hide_context, hold_context, use_context ??
>
> I still think it should be CONTEXT, period.  All the other options to
> RAISE are named directly after the message lines they control; why
> should this one be different?

I had a idea to set CONTEXT from RAISE statement - for forwarding data
from handled exception

some like

BEGIN   ...
EXCEPTION WHEN ... GET DIAGNOSTICS _context = PG_EXCEPTION_CONTEXT; REISE USING context = _context;
END;

Regards

Pavel Stehule

>
>                        regards, tom lane
>


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: .psqlrc version dependence (was Re: about EDITOR_LINENUMBER_SWITCH)
Следующее
От: Tom Lane
Дата:
Сообщение: Pushing ScalarArrayOpExpr support into the btree index AM