git.postgresql.org Git - postgresql.git/commitdiff

git projects / postgresql.git / commitdiff

Stabilize new plpgsql_record regression tests.

2018年2月14日 23:17:22 +0000 (18:17 -0500)

2018年2月14日 23:17:59 +0000 (18:17 -0500)

The buildfarm's CLOBBER_CACHE_ALWAYS animals aren't happy with some
of the test cases added in commit 4b93f5799. 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 9edc97b71).
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.

src/pl/plpgsql/src/expected/plpgsql_record.out patch | blob | blame | history

src/pl/plpgsql/src/sql/plpgsql_record.sql patch | blob | blame | history

diff --git a/src/pl/plpgsql/src/expected/plpgsql_record.out b/src/pl/plpgsql/src/expected/plpgsql_record.out

index 3f7cab208803a03f9ce65d4d5fcecb4c6377b1aa..29e42fda6c13d2c6eaf2f9b690c917ce3ed40905 100644 (file)

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

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

@@ -343,9 +343,12 @@ select getf1(row(1,2));

(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

diff --git a/src/pl/plpgsql/src/sql/plpgsql_record.sql b/src/pl/plpgsql/src/sql/plpgsql_record.sql

index 069d2643cfdd462b8323d7026045a8f953614727..781ccb0ccb53ec25f05b7bb314f837079ac6f50e 100644 (file)

--- a/src/pl/plpgsql/src/sql/plpgsql_record.sql

+++ b/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

This is the main PostgreSQL git repository.

RSS Atom