Clean up in the wake of TupleDescGetSlot() removal / 10763358c3f.

The previous commit wasn't careful enough to remove all traces of
TupleDescGetSlot().

Besides fixing the oversight of not removing TupleDescGetSlot()'s
declaration, this also removes FuncCallContext->slot. That was
documented to be for use in combination with TupleDescGetSlot(), a
cursory search over extensions finds no users, and there doesn't seem
to be convincing reasons to keep it around. If we later in the v12
release cycle find users, we can re-consider this part of the commit.

Reported-By: Michael Paquier
Discussion: https://postgr.es/m/[email protected]

1 files changed, 0 insertions, 16 deletions

diff --git a/src/backend/utils/fmgr/funcapi.c b/src/backend/utils/fmgr/funcapi.c
index d5984b415ed..30923518f5e 100644
--- a/src/backend/utils/fmgr/funcapi.c
+++ b/src/backend/utils/fmgr/funcapi.c
@@ -88,7 +88,6 @@ init_MultiFuncCall(PG_FUNCTION_ARGS)
 		 */
 		retval->call_cntr = 0;
 		retval->max_calls = 0;
-		retval->slot = NULL;
 		retval->user_fctx = NULL;
 		retval->attinmeta = NULL;
 		retval->tuple_desc = NULL;
@@ -129,21 +128,6 @@ per_MultiFuncCall(PG_FUNCTION_ARGS)
 {
 	FuncCallContext *retval = (FuncCallContext *) fcinfo->flinfo->fn_extra;
 
-	/*
-	 * Clear the TupleTableSlot, if present.  This is for safety's sake: the
-	 * Slot will be in a long-lived context (it better be, if the
-	 * FuncCallContext is pointing to it), but in most usage patterns the
-	 * tuples stored in it will be in the function's per-tuple context. So at
-	 * the beginning of each call, the Slot will hold a dangling pointer to an
-	 * already-recycled tuple.  We clear it out here.
-	 *
-	 * Note: use of retval->slot is obsolete as of 8.0, and we expect that it
-	 * will always be NULL.  This is just here for backwards compatibility in
-	 * case someone creates a slot anyway.
-	 */
-	if (retval->slot != NULL)
-		ExecClearTuple(retval->slot);
-
 	return retval;
 }