Re: PL/pgSQL, RAISE and error context

2015-04-24 13:16 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Fri, Apr 24, 2015 at 6:11 AM, Joel Jacobson <joel(at)trustly(dot)com> wrote:
> > Entering the discussion because this is a huge pain for me in my daily
> > work as well.
> >
> > This is not a reply to any specific post in this thread, but my first
> > message in the thread.
> >
> > I see a great value in providing both a GUC and a new RAISE syntax.
> > The different benefits of the two are maybe obvious, but perhaps worth
> > pointing out:
> > GUC: Good because you don't have to change any existing code.
> > RAISE syntax: Good because you can control exactly what message should
> > be emitted or not be emitted at that line of code.
> >
> > I think preserving backwards compatibility is very important.
> > Not changing the default is not a problem for me, as long as it can be
> > overridden.
> >
> > Whatever the default behaviour is, I think the need expressed by all
> > users in this thread boils down to any of these two sentences:
> >
> > "I want CONTEXT to be (DISPLAYED|SUPPRESSED) for (ALL|ONLY THIS LINE)
> > RAISE (NOTICE|WARNING|ERROR)"
> > OR
> > "I don't want to change the default current behaviour of CONTEXT"
> >
> > So we basically need a boolean setting value, where:
> > NULL means the default behaviour
> > TRUE means DISPLAY CONTEXT
> > FALSE means SUPPRESS CONTEXT
> >
> > And the (ALL|ONLY THIS) part translates into using,
> > * a GUC to change behaviour for ALL lines of code,
> > * or using the RAISE syntax to change the behaviour of ONLY THIS line of
> code.
> >
> > And then we have the different message levels, for which CONTEXT is
> > sometimes desirable in some situations:
> > * The RAISE syntax allows controlling any message level in a natural
> > way, as the message level is part of the syntax.
> > * Allowing the same control using GUC would mean the message level
> > would need to be part of the GUC key name, which means either add
> > multiple GUCs, one for each message level, or only allow controlling
> > the most important one and ignore the possibly need to control the
> > other message levels.
> >
> > If it would be possible to somehow combine multiple message levels in
> > the same GUC, that would solve the latter problem.
> >
> > We already have comma separated values for many GUCs, so maybe we
> > could use that approach here as well.
> >
> > It looks like adding these two GUCs would meet the demands of all users:
> >
> > suppress_context_messages (enum)
> > display_context_messages (enum)
> >
> > This would allow doing something crazy as:
> >
> > suppress_context_messages = warning,error
> > display_context_messages = notice
>
> This is a very flexible proposal, but it's a tremendous amount of
> machinery for what's really a very minor issue. If we added two GUCs
> for every comparably important issue, we'd have about 40,000 of them.
>

It can be PLpgSQL only GUC. Probably it is a most problematic case.

>
> I suggest we add the RAISE syntax first, because everybody agrees on
> that. Then, we can argue about the other stuff.
>

There is a agreement about it - but I am expecting a harder discussion
about what will be default, and the discussion about syntax should not be
simple too.

>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>