src/backend/utils/adt/ruleutils.c (1)

14413-14555: Guard missing relations and avoid emitting tuples for unresolved %TYPE references

The new use of RangeVarGetRelid(rel, NoLock, true) means relid_1 can legitimately be InvalidOid when the referenced relation does not exist. In that case:

• get_attnum(relid_1, field) is still called, which issues a syscache lookup with OID 0; while it happens to return InvalidAttrNumber, it’s safer and clearer not to query with an invalid OID at all.
• When either the relation is missing or the attribute name is wrong, attnum stays InvalidAttrNumber and is_valid_type remains false, yet the function still calls tuplestore_putvalues(*tupstore, tupdesc, values, nulls); with values[] never populated for this call. That can produce bogus rows (including zero OIDs) in the result, which undermines the goal of this change.

Two concrete fixes:

1. Only look up the attribute when relid_1 is valid, and keep is_valid_type false otherwise:

-        RangeVar   *rel = makeRangeVar(NULL, NULL, typeName->location);
-        char       *field = NULL;
-			Oid		relid_1;
+        RangeVar   *rel = makeRangeVar(NULL, NULL, typeName->location);
+        char       *field = NULL;
+        Oid        relid_1 = InvalidOid;
@@
-			relid_1 = RangeVarGetRelid(rel, NoLock, true);
-			attnum = get_attnum(relid_1, field);
-
-			if (attnum != InvalidAttrNumber)
-			{
-				get_atttypetypmodcoll(relid_1, attnum,
-									  &fieldTypeId, &fieldTypMod, &fieldCollation);
-
-				/* this construct should never have an array indicator */
-				Assert(typeName->arrayBounds == NIL);
-				is_valid_type = true;
-			}
+			relid_1 = RangeVarGetRelid(rel, NoLock, true);
+
+			if (OidIsValid(relid_1))
+			{
+				attnum = get_attnum(relid_1, field);
+
+				if (attnum != InvalidAttrNumber)
+				{
+					get_atttypetypmodcoll(relid_1, attnum,
+										  &fieldTypeId, &fieldTypMod, &fieldCollation);
+
+					/* this construct should never have an array indicator */
+					Assert(typeName->arrayBounds == NIL);
+					is_valid_type = true;
+				}
+			}

2. Only emit a row when the reference could actually be resolved (either to a rowtype or a valid scalar type); otherwise, silently skip the bad reference:

-	if (is_rowtype)
-	{
-		...
-	}
-	else if (is_valid_type)
-	{
-		...
-	}
-
-	tuplestore_putvalues(*tupstore, tupdesc, values, nulls);
+	if (is_rowtype)
+	{
+		...
+		tuplestore_putvalues(*tupstore, tupdesc, values, nulls);
+	}
+	else if (is_valid_type)
+	{
+		...
+		tuplestore_putvalues(*tupstore, tupdesc, values, nulls);
+	}
+	else
+	{
+		/* unresolved %TYPE/%ROWTYPE reference: nothing to emit */
+	}

This way unresolved %TYPE/%ROWTYPE references do not generate partially-initialized tuples, and syscache lookups are never performed with an invalid (0) relid.

src/pl/plisql/src/pl_comp.c (1)

3345-3451: compute_function_hashkey’s new protypenames logic leaks temporaries and assumes array length matches pronargs

The idea of deriving hashkey->argtypes[i] from pg_proc.protypenames (via TypeName/package or Oracle type lookup) is a good way to make the cache key sensitive to %TYPE/package-based argument types.

Two issues worth addressing:

1. Unfreed allocations in a potentially long‑lived context

Inside the if (procStruct->pronargs > 0) block:

• deconstruct_array allocates elems.
• argtypenames = (char **) palloc(sizeof(char *) * nelems);
• Each TextDatumGetCString(elems[i]) allocates a char *.

None of elems, argtypenames, or the per‑element strings are freed in this function. If compute_function_hashkey runs in a long‑lived context (e.g., TopMemoryContext or fn_mcxt via the call from plisql_compile / plisql_free_function), that becomes a permanent leak per compiled function / free‑call.

You can clean this up with minimal code churn by freeing per‑element strings in the loop and the arrays afterward, e.g.:

@@ -3401,6 +3401,10 @@ compute_function_hashkey(FunctionCallInfo fcinfo,
-        if (argtypenames != NULL)
-        {
-            for (i = 0; i < procStruct->pronargs; i++)
-            {
+        if (argtypenames != NULL)
+        {
+            for (i = 0; i < procStruct->pronargs; i++)
+            {
                 hashkey->argtypes[i] = procStruct->proargtypes.values[i];
                 if (strcmp(argtypenames[i], "") != 0)
                 {
@@ -3435,7 +3439,13 @@ compute_function_hashkey(FunctionCallInfo fcinfo,
 
-                    pfree(tname);
-                }
-            }
-        }
+                    pfree(tname);
+                }
+
+                /* `argtypenames[i]` was palloc'ed via TextDatumGetCString */
+                pfree(argtypenames[i]);
+            }
+
+            pfree(argtypenames);
+            pfree(elems);
+        }

(If you prefer, you can also just pfree(elems) and leave the text Datums to the context reset, following the usual deconstruct_array pattern.)

2. Implicit assumption that nelems == procStruct->pronargs

The loop iterates i < procStruct->pronargs but argtypenames has length nelems. The catalog should normally guarantee nelems == pronargs when protypenames is non‑NULL, but if that invariant is ever broken (corrupt row, partially initialized entry, etc.), you’d read past the end of argtypenames.

At minimum, an assertion or defensive clamp would make this more robust, for example:

Assert(nelems == procStruct->pronargs);
/* or */
int nused = Min(nelems, procStruct->pronargs);
for (i = 0; i < nused; i++)
    ...

Together these tweaks keep the new behavior while avoiding silent leaks and making the hashkey construction safer against catalog inconsistencies.