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
<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>
<!-- *********************************************** -->
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,