COPY inside plpgsql functions fails after first invocation?

[lithp]

brian=# CREATE FUNCTION doit() RETURNS void AS $$
BEGIN
  COPY (SELECT 'hi') TO '/home/brian/Work/pg-10/some_file';
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
brian=# SELECT doit();
 doit 
------
 
(1 row)

brian=# SELECT doit();
WARNING:  unrecognized node type: 2139062143
ERROR:  unexpected command tag "???"
CONTEXT:  SQL statement "COPY (SELECT 'hi') TO '/home/brian/Work/pg-10/some_file'"
PL/pgSQL function doit() line 3 at SQL statement

Even more tellingly:

brian=# CREATE FUNCTION doit() RETURNS void AS $$
BEGIN
  COPY (SELECT 'hi') TO '/home/brian/Work/pg-10/some_file';
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
brian=# SELECT doit();
 doit 
------
 
(1 row)

brian=# SELECT doit();
 doit 
------
 
(1 row)

brian=# SELECT doit();
 doit 
------
 
(1 row)

brian=# CREATE EXTENSION citus;
CREATE EXTENSION
brian=# SELECT doit();
 doit 
------
 
(1 row)

brian=# SELECT doit();
WARNING:  unrecognized node type: 9
ERROR:  unexpected command tag "???"
CONTEXT:  SQL statement "COPY (SELECT 'hi') TO '/home/brian/Work/pg-10/some_file'"
PL/pgSQL function doit() line 3 at SQL statement

[lithp]

This happens because of some code in multi_ProcessUtility which copies parsetree:

if (IsA(parsetree, CopyStmt))
{
	/* copy parse tree since we might scribble on it to fix the schema name */
	parsetree = copyObject(parsetree);

	parsetree = ProcessCopyStmt((CopyStmt *) parsetree, completionTag,
				    &commandMustRunAsOwner);

        ...
}

and then assigns the copy to pstmt->utilityStmt:

pstmt->utilityStmt = parsetree;
standard_ProcessUtility(pstmt, queryString, context,
			params, queryEnv, dest, completionTag);

(this code was added in 853f07d, which fixed COPY in plpgsql for distributed tables, but broke it for local tables.)

The problem is that, when we're inside plpgsql the plan gets cached and reused between statements. It belongs to a memory context which is a child of CacheMemoryContext. When we call copyObject, we create a copy which lives in the local executor context, which is reset at the end of the statement.

[lithp]

Fixed with #2128