Re: Inconsistency in plpgsql's error context reports

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2017-12-13T19:50:40Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Dec 11, 2017 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> 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).

> I confess to never having really grokked, even in the pre-patch state,
> why we sometimes get an "SQL statement" context line and sometimes
> not.  However, what strikes me about this is that the SQL statement is
> a completely fabricated one that the user never entered.

I spent a brief amount of time looking at whether we could hide the
"fabricated statements" more thoroughly, and decided that it would
be a lot more work than seems warranted, and there would likely be
holes in it anyway.  It's not like we don't document this behavior:
the plpgsql introductory material says

	All expressions used in PL/pgSQL statements are processed using
	the server's main SQL executor. For example, when you write a
	PL/pgSQL statement like

		IF expression THEN ...

	PL/pgSQL will evaluate the expression by feeding a query like

		SELECT expression

	to the main SQL engine.

https://www.postgresql.org/docs/devel/static/plpgsql-expressions.html

So basically my conclusion at this point is that I'm not willing
to do any more work on this than the patch I already proposed.
If you want to do something more invasive, have at it.

			regards, tom lane


Commits

  1. Stabilize output of new regression test case.

  2. Fix plpgsql to reinitialize record variables at block re-entry.