Re: PL/pgSQL, RAISE and error context

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL, RAISE and error context
Date: 2015-09-04 19:51:35
Message-ID: 8885.1441396295@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2015-08-12 11:07 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vignesh Raghunathan 2015-09-04 20:45:05 What is the length of tuple with a TOAST pointer?
Previous Message Bruce Momjian 2015-09-04 19:48:19 Re: WIP: SCRAM authentication