1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-03 09:13:20 +03:00

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

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/20180926000413.GC1659@paquier.xyz
This commit is contained in:
Andres Freund
2018-09-27 11:24:49 -07:00
parent ea53100d56
commit 27e082b0c6
3 changed files with 0 additions and 35 deletions

View File

@@ -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;
}