Re: PL/pgSQL, RAISE and error context - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PL/pgSQL, RAISE and error context
Date
Msg-id 8885.1441396295@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/pgSQL, RAISE and error context  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: PL/pgSQL, RAISE and error context  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2015-08-12 11:07 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
>> I'm somewhat worried that this is hiding important context from some
>> NOTICE or WARNING messages intended for novice users, but probably not
>> worried enough to go through all of them.  +3/8 from me, I guess.

> I fixed mentioned issues.

Okay, so to summarize where we seem to have ended up:

1. Remove the wart in plpgsql that causes it to suppress the innermost
CONTEXT line for RAISE.  (I think pretty much everyone agrees that this
*is* a wart.  The question is how to get rid of it without a decrease
in usability for simple cases.)

2. Change psql so that by default, it hides the entire CONTEXT output
for messages that are of less than ERROR severity.  Add a new magic
\set variable that allows choosing this behavior, or display CONTEXT
always, or display CONTEXT never.

3. Since psql actually uses libpq for formatting server messages,
add an API to libpq that implements these CONTEXT hide/show options.

The actual code changes are pretty small, but there's rather a large
change in regression test outputs; which is unsurprising, because this
heuristic for what's of interest is entirely different from the old one.

Is everyone satisfied with this solution?  It's okay with me, though
I'm concerned that there will be complaints about loss of backwards
compatibility.  (It's hard to see how the contents of CONTEXT error
fields would be a big application compatibility issue, but you never
know.)

If there are not major objections, I'll work on cleaning up and
committing the patch.  There is still work needed (eg, the API addition
of point 3 is undocumented), but the main question is just whether we
are happy with making things work this way.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: WIP: SCRAM authentication
Next
From: Vignesh Raghunathan
Date:
Subject: What is the length of tuple with a TOAST pointer?