Fix plpgsql to re-look-up composite type names at need.

Commit 4b93f57 rearranged things in plpgsql to make it cope better with
composite types changing underneath it intra-session.  However, I failed to
consider the case of a composite type being dropped and recreated entirely.
In my defense, the previous coding didn't consider that possibility at all
either --- but it would accidentally work so long as you didn't change the
type's field list, because the built-at-compile-time list of component
variables would then still match the type's new definition.  The new
coding, however, occasionally tries to re-look-up the type by OID, and
then fails to find the dropped type.

To fix this, we need to save the TypeName struct, and then redo the type
OID lookup from that.  Of course that's expensive, so we don't want to do
it every time we need the type OID.  This can be fixed in the same way that
4b93f57 dealt with changes to composite types' definitions: keep an eye
on the type's typcache entry to see if its tupledesc has been invalidated.
(Perhaps, at some point, this mechanism should be generalized so it can
work for non-composite types too; but for now, plpgsql only tries to
cope with intra-session redefinitions of composites.)

I'm slightly hesitant to back-patch this into v11, because it changes
the contents of struct PLpgSQL_type as well as the signature of
plpgsql_build_datatype(), so in principle it could break code that is
poking into the innards of plpgsql.  However, the only popular extension
of that ilk is pldebugger, and it doesn't seem to be affected.  Since
this is a regression for people who were relying on the old behavior,
it seems worth taking the small risk of causing compatibility issues.

Per bug #15913 from Daniel Fiori.  Back-patch to v11 where 4b93f57
came in.

Discussion: https://postgr.es/m/15913-a7e112e16dedcffc@postgresql.org

Author: tglsfdc

src/backend/utils/cache/typcache.c

@@ -2116,6 +2116,16 @@ TypeCacheRelCallback(Datum arg, Oid relid)
 				if (--typentry->tupDesc->tdrefcount == 0)
 					FreeTupleDesc(typentry->tupDesc);
 				typentry->tupDesc = NULL;
+
+				/*
+				 * Also clear tupDesc_identifier, so that anything watching
+				 * that will realize that the tupdesc has possibly changed.
+				 * (Alternatively, we could specify that to detect possible
+				 * tupdesc change, one must check for tupDesc != NULL as well
+				 * as tupDesc_identifier being the same as what was previously
+				 * seen.  That seems error-prone.)
+				 */
+				typentry->tupDesc_identifier = 0;
 			}
 
 			/* Reset equality/comparison/hashing validity information */

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

@@ -447,6 +447,35 @@ alter table mutable drop column f3;
 select getf3(null::mutable);  -- fails again
 ERROR:  record "x" has no field "f3"
 \set SHOW_CONTEXT errors
+-- check behavior with creating/dropping a named rowtype
+set check_function_bodies = off;  -- else reference to nonexistent type fails
+create function sillyaddtwo(int) returns int language plpgsql as
+$$ declare r mutable2; begin r.f1 := $1; return r.f1 + 2; end $$;
+reset check_function_bodies;
+select sillyaddtwo(42);  -- fail
+ERROR:  type "mutable2" does not exist
+LINE 1:  declare r mutable2; begin r.f1 := $1; return r.f1 + 2; end 
+                   ^
+QUERY:   declare r mutable2; begin r.f1 := $1; return r.f1 + 2; end 
+CONTEXT:  compilation of PL/pgSQL function "sillyaddtwo" near line 1
+create table mutable2(f1 int, f2 text);
+select sillyaddtwo(42);
+ sillyaddtwo 
+-------------
+          44
+(1 row)
+
+drop table mutable2;
+select sillyaddtwo(42);  -- fail
+ERROR:  type "mutable2" does not exist
+CONTEXT:  PL/pgSQL function sillyaddtwo(integer) line 1 at assignment
+create table mutable2(f0 text, f1 int, f2 text);
+select sillyaddtwo(42);
+ sillyaddtwo 
+-------------
+          44
+(1 row)
+
 -- check access to system columns in a record variable
 create function sillytrig() returns trigger language plpgsql as
 $$begin