Provide plpgsql tests for cases involving record field changes.

We suppressed one of these test cases in commit feb1cc559 because
it was failing to produce the expected results on CLOBBER_CACHE_ALWAYS
buildfarm members.  But now we need another test with similar behavior,
so let's set up a test file that is expected to vary between regular and
CLOBBER_CACHE_ALWAYS cases, and provide variant expected files.

Someday we should fix plpgsql's failure for change-of-field-type, and
then the discrepancy will go away and we can fold these tests back
into plpgsql_record.sql.  But today is not that day.

Discussion: https://postgr.es/m/87wotkfju1.fsf@news-spur.riddles.org.uk
This commit is contained in:
Tom Lane 2018-07-26 18:18:37 -04:00
parent 662d12aea1
commit 9f77ad2672
6 changed files with 194 additions and 26 deletions

View File

@ -27,7 +27,7 @@ DATA = plpgsql.control plpgsql--1.0.sql plpgsql--unpackaged--1.0.sql
REGRESS_OPTS = --dbname=$(PL_TESTDB)
REGRESS = plpgsql_call plpgsql_control plpgsql_domain plpgsql_record \
plpgsql_transaction plpgsql_varprops
plpgsql_cache plpgsql_transaction plpgsql_varprops
all: all-lib

View File

@ -0,0 +1,67 @@
--
-- Cache-behavior-dependent test cases
--
-- These tests logically belong in plpgsql_record.sql, and perhaps someday
-- can be merged back into it. For now, however, their results are different
-- between regular and CLOBBER_CACHE_ALWAYS builds, so we must have two
-- expected-output files to cover both cases. To minimize the maintenance
-- effort resulting from that, this file should contain only tests that
-- do have different results under CLOBBER_CACHE_ALWAYS.
--
-- check behavior with changes of a named rowtype
create table c_mutable(f1 int, f2 text);
create function c_sillyaddone(int) returns int language plpgsql as
$$ declare r c_mutable; begin r.f1 := $1; return r.f1 + 1; end $$;
select c_sillyaddone(42);
c_sillyaddone
---------------
43
(1 row)
alter table c_mutable drop column f1;
alter table c_mutable add column f1 float8;
-- currently, this fails due to cached plan for "r.f1 + 1" expression
-- (but a CLOBBER_CACHE_ALWAYS build will succeed)
select c_sillyaddone(42);
ERROR: type of parameter 4 (double precision) does not match that when preparing the plan (integer)
CONTEXT: PL/pgSQL function c_sillyaddone(integer) line 1 at RETURN
-- but it's OK if we force plan rebuilding
discard plans;
select c_sillyaddone(42);
c_sillyaddone
---------------
43
(1 row)
-- check behavior with changes in a record rowtype
create function show_result_type(text) returns text language plpgsql as
$$
declare
r record;
t text;
begin
execute $1 into r;
select pg_typeof(r.a) into t;
return format('type %s value %s', t, r.a::text);
end;
$$;
select show_result_type('select 1 as a');
show_result_type
----------------------
type integer value 1
(1 row)
-- currently this fails due to cached plan for pg_typeof expression
-- (but a CLOBBER_CACHE_ALWAYS build will succeed)
select show_result_type('select 2.0 as a');
ERROR: type of parameter 5 (numeric) does not match that when preparing the plan (integer)
CONTEXT: SQL statement "select pg_typeof(r.a)"
PL/pgSQL function show_result_type(text) line 7 at SQL statement
-- but it's OK if we force plan rebuilding
discard plans;
select show_result_type('select 2.0 as a');
show_result_type
------------------------
type numeric value 2.0
(1 row)

View File

@ -0,0 +1,72 @@
--
-- Cache-behavior-dependent test cases
--
-- These tests logically belong in plpgsql_record.sql, and perhaps someday
-- can be merged back into it. For now, however, their results are different
-- between regular and CLOBBER_CACHE_ALWAYS builds, so we must have two
-- expected-output files to cover both cases. To minimize the maintenance
-- effort resulting from that, this file should contain only tests that
-- do have different results under CLOBBER_CACHE_ALWAYS.
--
-- check behavior with changes of a named rowtype
create table c_mutable(f1 int, f2 text);
create function c_sillyaddone(int) returns int language plpgsql as
$$ declare r c_mutable; begin r.f1 := $1; return r.f1 + 1; end $$;
select c_sillyaddone(42);
c_sillyaddone
---------------
43
(1 row)
alter table c_mutable drop column f1;
alter table c_mutable add column f1 float8;
-- currently, this fails due to cached plan for "r.f1 + 1" expression
-- (but a CLOBBER_CACHE_ALWAYS build will succeed)
select c_sillyaddone(42);
c_sillyaddone
---------------
43
(1 row)
-- but it's OK if we force plan rebuilding
discard plans;
select c_sillyaddone(42);
c_sillyaddone
---------------
43
(1 row)
-- check behavior with changes in a record rowtype
create function show_result_type(text) returns text language plpgsql as
$$
declare
r record;
t text;
begin
execute $1 into r;
select pg_typeof(r.a) into t;
return format('type %s value %s', t, r.a::text);
end;
$$;
select show_result_type('select 1 as a');
show_result_type
----------------------
type integer value 1
(1 row)
-- currently this fails due to cached plan for pg_typeof expression
-- (but a CLOBBER_CACHE_ALWAYS build will succeed)
select show_result_type('select 2.0 as a');
show_result_type
------------------------
type numeric value 2.0
(1 row)
-- but it's OK if we force plan rebuilding
discard plans;
select show_result_type('select 2.0 as a');
show_result_type
------------------------
type numeric value 2.0
(1 row)

View File

@ -421,20 +421,8 @@ select sillyaddone(42);
43
(1 row)
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
-- (but we can't actually show that, because a CLOBBER_CACHE_ALWAYS build
-- will succeed)
-- select sillyaddone(42);
-- but it's OK if we force plan rebuilding
discard plans;
select sillyaddone(42);
sillyaddone
-------------
43
(1 row)
-- test for change of type of column f1 should be here someday;
-- for now see plpgsql_cache test
alter table mutable drop column f1;
select sillyaddone(42); -- fail
ERROR: record "r" has no field "f1"

View File

@ -0,0 +1,50 @@
--
-- Cache-behavior-dependent test cases
--
-- These tests logically belong in plpgsql_record.sql, and perhaps someday
-- can be merged back into it. For now, however, their results are different
-- between regular and CLOBBER_CACHE_ALWAYS builds, so we must have two
-- expected-output files to cover both cases. To minimize the maintenance
-- effort resulting from that, this file should contain only tests that
-- do have different results under CLOBBER_CACHE_ALWAYS.
--
-- check behavior with changes of a named rowtype
create table c_mutable(f1 int, f2 text);
create function c_sillyaddone(int) returns int language plpgsql as
$$ declare r c_mutable; begin r.f1 := $1; return r.f1 + 1; end $$;
select c_sillyaddone(42);
alter table c_mutable drop column f1;
alter table c_mutable add column f1 float8;
-- currently, this fails due to cached plan for "r.f1 + 1" expression
-- (but a CLOBBER_CACHE_ALWAYS build will succeed)
select c_sillyaddone(42);
-- but it's OK if we force plan rebuilding
discard plans;
select c_sillyaddone(42);
-- check behavior with changes in a record rowtype
create function show_result_type(text) returns text language plpgsql as
$$
declare
r record;
t text;
begin
execute $1 into r;
select pg_typeof(r.a) into t;
return format('type %s value %s', t, r.a::text);
end;
$$;
select show_result_type('select 1 as a');
-- currently this fails due to cached plan for pg_typeof expression
-- (but a CLOBBER_CACHE_ALWAYS build will succeed)
select show_result_type('select 2.0 as a');
-- but it's OK if we force plan rebuilding
discard plans;
select show_result_type('select 2.0 as a');

View File

@ -270,17 +270,8 @@ create function sillyaddone(int) returns int language plpgsql as
$$ declare r mutable; begin r.f1 := $1; return r.f1 + 1; end $$;
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
-- (but we can't actually show that, because a CLOBBER_CACHE_ALWAYS build
-- will succeed)
-- select sillyaddone(42);
-- but it's OK if we force plan rebuilding
discard plans;
select sillyaddone(42);
-- test for change of type of column f1 should be here someday;
-- for now see plpgsql_cache test
alter table mutable drop column f1;
select sillyaddone(42); -- fail