Hello, I've been trying to play with support functions for a use-case of ours, and found some behaviors I don't know are expected or not.
The use case: we have some complicated queries, where whole-branches of the execution tree could be cut if some things were evaluated at planning time. Take the following simplified example: CREATE OR REPLACE FUNCTION myfunction(t1_id int) AS $$ SELECT * FROM sometable t1 JOIN sometable t2 on t2.t1_id = t1.id WHERE id = t1_id AND t1.somecolumn IS NOT NULL $$ language SQL; If I were to incorporate this function in a larger query, the planner will choose a plan based on a generic value of t1_id and may estimate a large rowcount after inlining. What I want to do is to evaluate whether id = t1_id AND somecolumn is NOT NULL at planification time, and replace the function by another one if this can be pruned altogether. So, what I've been doing is to implement a support function for SupportRequestSimplify, and If the predicate doesn't match any row, replace the FuncExpr by a new one, calling a different function. This seems to work great, but I have several questions: 1) Is it valid to make SPI calls in a support function to do this kind of simplification ? 2) My new FuncExpr doesn't get inlined. This is because in inline_set_returning_function, we check that after the call to eval_const_expressions we still call the same function. I think it would be better to first simplify the function if we can, and only then record the function oid and call the rest of the machinery. I tested that naively by calling eval_const_expressions early in inline_set_returning_function and it seems to do the trick. A proper patch would likely only call the support function at this stage. What do you think ? -- This e-mail message and any attachments to it are intended only for the named recipients and may contain legally privileged and/or confidential information. If you are not one of the intended recipients, do not duplicate or forward this e-mail message.
