--

-- 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

--depending on debug_invalidate_system_caches_always, 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 underCLOBBER_CACHE_ALWAYS.

-- do have different results underdebug_invalidate_system_caches_always.

--

-- check behavior with changes of a named rowtype

create table c_mutable(f1 int, f2 text);

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

-- (buta CLOBBER_CACHE_ALWAYS build will succeed)

-- (butif debug_invalidate_system_caches_always is on, it 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

(1 row)

-- currently this fails due to cached plan for pg_typeof expression

-- (buta CLOBBER_CACHE_ALWAYS build will succeed)

-- (butif debug_invalidate_system_caches_always is on, it 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)"

--

-- 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

--depending on debug_invalidate_system_caches_always, 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 underCLOBBER_CACHE_ALWAYS.

-- do have different results underdebug_invalidate_system_caches_always.

--

-- check behavior with changes of a named rowtype

create table c_mutable(f1 int, f2 text);

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

-- (buta CLOBBER_CACHE_ALWAYS build will succeed)

-- (butif debug_invalidate_system_caches_always is on, it will succeed)

select c_sillyaddone(42);

c_sillyaddone

---------------

(1 row)

-- currently this fails due to cached plan for pg_typeof expression

-- (buta CLOBBER_CACHE_ALWAYS build will succeed)

-- (butif debug_invalidate_system_caches_always is on, it will succeed)

select show_result_type('select 2.0 as a');

show_result_type

------------------------

1

(1 row)

--a CLOBBER_CACHE_ALWAYS build will report this error with a different

--context stack than other builds, so suppress context output

--the context stack is different when debug_invalidate_system_caches_always

--is set, so suppress context output

\set SHOW_CONTEXT never

select getf1(row(1,2)::two_int8s);

ERROR: record "x" has no field "f1"

-- test for change of type of column f1 should be here someday;

-- for now see plpgsql_cache test

alter table mutable drop column f1;

-- the context stack is different when debug_invalidate_system_caches_always

-- is set, so suppress context output

\set SHOW_CONTEXT never

select sillyaddone(42); -- fail

ERROR: record "r" has no field "f1"

create function getf3(x mutable) returns int language plpgsql as

$$ begin return x.f3; end $$;

select getf3(null::mutable); -- doesn't work yet

(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

--the context stack is different when debug_invalidate_system_caches_always

--is set, so suppress context output

\set SHOW_CONTEXT never

select getf3(null::mutable); -- fails again

ERROR: record "x" has no field "f3"

(1 row)

drop table mutable2;

-- the context stack is different when debug_invalidate_system_caches_always

-- is set, so suppress context output

\set SHOW_CONTEXT never

select sillyaddtwo(42); -- fail

ERROR: type "mutable2" does not exist

create table mutable2(f0 text, f1 int, f2 text);

select sillyaddtwo(42);

sillyaddtwo

altertable c_mutable add column f1 float8;

select c_sillyaddone(42);

select show_result_type('select 1 as a');

select show_result_type('select 2.0 as a');

$$begin returnx.f1; end $$;

select getf1(1);

select getf1(row(1,2));

\set SHOW_CONTEXT never

select getf1(row(1,2)::two_int8s);

\set SHOW_CONTEXT errors

altertable mutable drop column f1;

\set SHOW_CONTEXT never

select sillyaddone(42);-- fail

\set SHOW_CONTEXT errors

createfunctiongetf3(x mutable) returnsint language plpgsqlas

$$begin returnx.f3; end $$;

select getf3(null::mutable);-- doesn't work yet

altertable mutable add column f3int;

select getf3(null::mutable);-- now it works

altertable mutable drop column f3;

\set SHOW_CONTEXT never

select getf3(null::mutable);-- fails again

\set SHOW_CONTEXT errors

createtablemutable2(f1int, f2text);

select sillyaddtwo(42);

droptable mutable2;

\set SHOW_CONTEXT never

select sillyaddtwo(42);-- fail

\set SHOW_CONTEXT errors

createtablemutable2(f0text, f1int, f2text);

select sillyaddtwo(42);

select sillyaddtwo(43);