• Tom Lane's avatar
    Allow functions-in-FROM to be pulled up if they reduce to constants. · 7266d099
    Tom Lane authored
    This allows simplification of the plan tree in some common usage
    patterns: we can get rid of a join to the function RTE.
    
    In principle we could pull up any immutable expression, but restricting
    it to Consts avoids the risk that multiple evaluations of the expression
    might cost more than we can save.  (Possibly this could be improved in
    future --- but we've more or less promised people that putting a function
    in FROM guarantees single evaluation, so we'd have to tread carefully.)
    
    To do this, we need to rearrange when eval_const_expressions()
    happens for expressions in function RTEs.  I moved it to
    inline_set_returning_functions(), which already has to iterate over
    every function RTE, and in consequence renamed that function to
    preprocess_function_rtes().  A useful consequence is that
    inline_set_returning_function() no longer has to do this for itself,
    simplifying that code.
    
    In passing, break out pull_up_simple_subquery's code that knows where
    everything that needs pullup_replace_vars() processing is, so that
    the new pull_up_constant_function() routine can share it.  We'd
    gotten away with one-and-a-half copies of that code so far, since
    pull_up_simple_values() could assume that a lot of cases didn't apply
    to it --- but I don't think pull_up_constant_function() can make any
    simplifying assumptions.  Might as well make pull_up_simple_values()
    use it too.
    
    (Possibly this refactoring should go further: maybe we could share
    some of the code to fill in the pullup_replace_vars_context struct?
    For now, I left it that the callers fill that completely.)
    
    Note: the one existing test case that this patch changes has to be
    changed because inlining its function RTEs would destroy the point
    of the test, namely to check join order.
    
    Alexander Kuzmenkov and Aleksandr Parfenov, reviewed by
    Antonin Houska and Anastasia Lubennikova, and whacked around
    some more by me
    
    Discussion: https://postgr.es/m/402356c32eeb93d4fed01f66d6c7fe2d@postgrespro.ru
    7266d099
prep.h 1.3 KB