Re: Inconsistency in plpgsql's error context reports

On Mon, Dec 11, 2017 at 3:52 PM, Tom Lane wrote: > Here's a quick hack at that. I guess the main question that needs to be > asked is whether we're happy with plpgsql getting so much chattier > (as per all the regression test changes). > > If we're not, the alternative that

Re: Inconsistency in plpgsql's error context reports

I wrote: > Robert Haas writes: >> On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: >>> There seem to be two ways we could look at this. One is that the >>> new test case just needs to be rejiggered to avoid unstable output >>> ("\set VERBOSITY terse"

Re: Inconsistency in plpgsql's error context reports

Robert Haas writes: > On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: >> There seem to be two ways we could look at this. One is that the >> new test case just needs to be rejiggered to avoid unstable output >> ("\set VERBOSITY terse" would be the

Re: Inconsistency in plpgsql's error context reports

On Sun, Dec 10, 2017 at 11:55 AM, Tom Lane wrote: > There seem to be two ways we could look at this. One is that the > new test case just needs to be rejiggered to avoid unstable output > ("\set VERBOSITY terse" would be the easiest way). But there is > also room to argue

Inconsistency in plpgsql's error context reports

I noticed that since I put in commit 390d58135, buildfarm members that use CLOBBER_CACHE_ALWAYS are failing the added test case with diffs like *** 5051,5057 NOTICE: y = 2 ERROR: record "r" is not assigned yet DETAIL: The tuple structure of a not-yet-assigned record is