Stabilize new plpgsql_record regression tests.

The buildfarm's CLOBBER_CACHE_ALWAYS animals aren't happy with some
of the test cases added in commit 4b93f57.  There are two different
problems:

* In two places, a different CONTEXT stack is shown because the error
is detected in a different place, due to recompiling an expression
from scratch rather than re-using a previously cached plan for it.
I fixed these via the expedient of hiding the CONTEXT stack altogether.

* In one place, a test expected to fail (because a cached plan hadn't
been updated) actually succeeds (because the forced recompile makes
it good).  I couldn't think of a simple workaround for this, so I've
just commented out that test step altogether.

I have hopes of improving things enough that both of these kluges can
be reverted eventually.  The first one is the same kind of problem
previously discussed at
https://postgr.es/m/31545.1512924904@sss.pgh.pa.us
but there was insufficient agreement about how to fix it, so we
just hacked around the output instability (commit 9edc97b).
The second issue should be fixed by allowing the plan to be rebuilt
when a type conflict is detected.  But for today, let's just make the
buildfarm green again.

Author: tglsfdc

src/pl/plpgsql/src/expected/plpgsql_record.out

@@ -343,9 +343,12 @@ select getf1(row(1,2));
      1
 (1 row)
 
+-- a CLOBBER_CACHE_ALWAYS build will report this error with a different
+-- context stack than other builds, so suppress context output
+\set SHOW_CONTEXT never
 select getf1(row(1,2)::two_int8s);
 ERROR:  record "x" has no field "f1"
-CONTEXT:  PL/pgSQL function getf1(record) line 1 at RETURN
+\set SHOW_CONTEXT errors
 select getf1(row(1,2));
  getf1 
 -------
@@ -421,9 +424,7 @@ select sillyaddone(42);
 alter table mutable drop column f1;
 alter table mutable add column f1 float8;
 -- currently, this fails due to cached plan for "r.f1 + 1" expression
-select sillyaddone(42);
-ERROR:  type of parameter 4 (double precision) does not match that when preparing the plan (integer)
-CONTEXT:  PL/pgSQL function sillyaddone(integer) line 1 at RETURN
+-- select sillyaddone(42);
 \c -
 -- but it's OK after a reconnect
 select sillyaddone(42);
@@ -450,9 +451,12 @@ select getf3(null::mutable);  -- now it works
 (1 row)
 
 alter table mutable drop column f3;
+-- a CLOBBER_CACHE_ALWAYS build will report this error with a different
+-- context stack than other builds, so suppress context output
+\set SHOW_CONTEXT never
 select getf3(null::mutable);  -- fails again
 ERROR:  record "x" has no field "f3"
-CONTEXT:  PL/pgSQL function getf3(mutable) line 1 at RETURN
+\set SHOW_CONTEXT errors
 -- check access to system columns in a record variable
 create function sillytrig() returns trigger language plpgsql as
 $$begin

src/pl/plpgsql/src/sql/plpgsql_record.sql

@@ -215,7 +215,11 @@ create function getf1(x record) returns int language plpgsql as
 $$ begin return x.f1; end $$;
 select getf1(1);
 select getf1(row(1,2));
+-- a CLOBBER_CACHE_ALWAYS build will report this error with a different
+-- context stack than other builds, so suppress context output
+\set SHOW_CONTEXT never
 select getf1(row(1,2)::two_int8s);
+\set SHOW_CONTEXT errors
 select getf1(row(1,2));
 
 -- check behavior when assignment to FOR-loop variable requires coercion
@@ -270,7 +274,7 @@ alter table mutable drop column f1;
 alter table mutable add column f1 float8;
 
 -- currently, this fails due to cached plan for "r.f1 + 1" expression
-select sillyaddone(42);
+-- select sillyaddone(42);
 \c -
 -- but it's OK after a reconnect
 select sillyaddone(42);
@@ -284,7 +288,11 @@ select getf3(null::mutable);  -- doesn't work yet
 alter table mutable add column f3 int;
 select getf3(null::mutable);  -- now it works
 alter table mutable drop column f3;
+-- a CLOBBER_CACHE_ALWAYS build will report this error with a different
+-- context stack than other builds, so suppress context output
+\set SHOW_CONTEXT never
 select getf3(null::mutable);  -- fails again
+\set SHOW_CONTEXT errors
 
 -- check access to system columns in a record variable