pgsql: Simplify plpgsql's check for simple expressions.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Simplify plpgsql's check for simple expressions.
Date: 2017-08-15 16:28:46
Message-ID: E1dhehy-00034e-8N@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/00418c61244138bd8ac2de58076a1d0dd4f539f3

Modified Files
--------------
src/backend/optimizer/util/clauses.c | 5 +
src/pl/plpgsql/src/pl_exec.c | 387 +++++------------------------------
2 files changed, 53 insertions(+), 339 deletions(-)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2017-08-15 16:33:01 pgsql: Assorted preparatory refactoring for partition-wise join.
Previous Message Michael Meskes 2017-08-15 15:14:59 pgsql: Allow continuation lines in ecpg cppline parsing.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-15 16:45:11 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Christoph Berg 2017-08-15 16:08:08 Re: Log LDAP "diagnostic messages"?