Don't crash if cursor_to_xmlschema is used on a non-data-returning Portal.

cursor_to_xmlschema() assumed that any Portal must have a tupDesc,
which is not so.  Add a defensive check.

It's plausible that this mistake occurred because of the rather
poorly chosen name of the lookup function SPI_cursor_find(),
which in such cases is returning something that isn't very much
like a cursor.  Add some documentation to try to forestall future
errors of the same ilk.

Report and patch by Boyu Yang (docs changes by me).  Back-patch
to all supported branches.

Discussion: https://postgr.es/m/dd343010-c637-434c-a8cb-418f53bda3b8.yangboyu.yby@alibaba-inc.com

Author: tglsfdc

doc/src/sgml/spi.sgml

@@ -2727,6 +2727,19 @@ Portal SPI_cursor_find(const char * <parameter>name</parameter>)
    <symbol>NULL</symbol> if none was found
   </para>
  </refsect1>
+
+ <refsect1>
+  <title>Notes</title>
+
+  <para>
+   Beware that this function can return a <type>Portal</type> object
+   that does not have cursor-like properties; for example it might not
+   return tuples.  If you simply pass the <type>Portal</type> pointer
+   to other SPI functions, they can defend themselves against such
+   cases, but caution is appropriate when directly inspecting
+   the <type>Portal</type>.
+  </para>
+ </refsect1>
 </refentry>
 
 <!-- *********************************************** -->

src/backend/utils/adt/xml.c

@@ -3012,6 +3012,10 @@ cursor_to_xmlschema(PG_FUNCTION_ARGS)
 		ereport(ERROR,
 				(errcode(ERRCODE_UNDEFINED_CURSOR),
 				 errmsg("cursor \"%s\" does not exist", name)));
+	if (portal->tupDesc == NULL)
+		ereport(ERROR,
+				(errcode(ERRCODE_INVALID_CURSOR_STATE),
+				 errmsg("portal \"%s\" does not return tuples", name)));
 
 	xmlschema = _SPI_strdup(map_sql_table_to_xmlschema(portal->tupDesc,
 													   InvalidOid, nulls,