Latest version of patch. This should be it as far as code goes; there
may be some more regression test work, and a doc patch will be
forthcoming.
This version supports, in addition to the previous stuff:
SELECT ... FROM TABLE(func() AS (colname coltype, ...));
i.e. the column definition list required for functions that return
arbitrary RECORD results can go inside the TABLE() construct. This
allows more than one such function in a call:
SELECT ... FROM TABLE(func1() AS (a integer), func2() AS (b text));
or mixing RECORD functions with ORDINALITY:
SELECT ... FROM TABLE(func1() AS (c text)) WITH ORDINALITY;
The existing FROM func() AS f(c text) is still supported of course,
and the variation FROM TABLE(func()) AS f(c text) is also supported
but only when there's exactly one function and no ORDINALITY.
Other changes:
- function dependence on executor parameters is now tracked
per-function, so that on rescan, only affected functions are
re-executed, and others are simply rescanned from the existing
tuplestore
- some cases where deparse or other code broke because an element
of funcexprs was not actually a FuncExpr have been fixed
- fixed the pg_stat_statements issue
A change I _didn't_ include, but did test, was adding mark/restore to
FunctionScan to allow mergejoins on ordinality columns to work without
needing extra nodes (which I did to do some performance tests referred
to in a previous message). I took this code back out because it didn't
seem to make much difference: the planner often (not always) adds the
Materialize node even when it's not needed, in the belief that it is
faster; the overhead of the extra node doesn't seem serious; and the
case is of limited applicability (only useful when joining against
something other than a function using the ordinal column alone).
--
Andrew (irc:RhodiumToad)
