Re: Call stacks and RAISE INFO - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Call stacks and RAISE INFO
Date
Msg-id CAFj8pRALU0VkxWyj2jaAeKjy6zjUVW_z9217mkcaFcSBhVM1fQ@mail.gmail.com
Whole thread Raw
In response to Re: Call stacks and RAISE INFO  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: .psqlrc version dependence (was Re: about EDITOR_LINENUMBER_SWITCH)
Next
From: Tom Lane
Date:
Subject: Pushing ScalarArrayOpExpr support into the btree index AM