]> granicus.if.org Git - postgresql/commit
Simplify plpgsql's check for simple expressions.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 15 Aug 2017 16:28:39 +0000 (12:28 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 15 Aug 2017 16:28:39 +0000 (12:28 -0400)
commit00418c61244138bd8ac2de58076a1d0dd4f539f3
tree3ebfc33685a18453236d1a6f124eb1a5b3da4d78
parenta4619b26a6a69ab31cab4a0632460647d7f5510f
Simplify plpgsql's check for simple expressions.

plpgsql wants to recognize expressions that it can execute directly
via ExecEvalExpr() instead of going through the full SPI machinery.
Originally the test for this consisted of recursively groveling through
the post-planning expression tree to see if it contained only nodes that
plpgsql recognized as safe.  That was a major maintenance headache, since
it required updating plpgsql every time we added any kind of expression
node.  It was also kind of expensive, so over time we added various
pre-planning checks to try to short-circuit having to do that.
Robert Haas pointed out that as of the SRF-processing changes in v10,
particularly the addition of Query.hasTargetSRFs, there really isn't
any reason to make the recursive scan at all: the initial checks cover
everything we really care about.  We do have to make sure that those
checks agree with what inline_function() considers, so that inlining
of a function that formerly wasn't inlined can't cause an expression
considered simple to become non-simple.

Hence, delete the recursive function exec_simple_check_node(), and tweak
those other tests to more exactly agree with inline_function().  Adjust
some comments and function naming to match.

Discussion: https://postgr.es/m/CA+TgmoZGZpwdEV2FQWaVxA_qZXsQE1DAS5Fu8fwxXDNvfndiUQ@mail.gmail.com
src/backend/optimizer/util/clauses.c
src/pl/plpgsql/src/pl_exec.c