Hi, On 2020-07-23 22:34:53 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I'm a bit worried about a case like: > > > CREATE FUNCTION yell(int, int) > > RETURNS int > > IMMUTABLE > > LANGUAGE SQL AS $$ > > SELECT CASE WHEN $1 != 0 THEN 17 / $2 ELSE NULL END > > $$; > > > EXPLAIN SELECT yell(g.i, 0) FROM generate_series(1, 10) g(i); > > > I don't think the parameters here would have been handled before > > inlining, right? > > Ah, I see what you mean. Yeah, that throws an error today, and it > still would with the patch I was envisioning (attached), because > inlining does Param substitution in a different way. I'm not > sure that we could realistically fix the inlining case with this > sort of approach.
Thinking about it a bit it seems we could solve that fairly easy if we don't replace function parameter with actual Const nodes, but instead with a PseudoConst parameter. If we map that to the same expression evaluation step that should be fairly cheap to implement, basically adding a bunch of 'case PseudoConst:' to the Const cases. That way we could take the type of constness into account before constant folding. Alternatively we could add a new field to Const, indicating the 'source' or 'context of the Const, which we then could take into account during constant evaluation. > I think this bears out the comment I made before that this approach > still leaves us with a very complicated behavior. Maybe we should > stick with the previous approach, possibly supplemented with a > leakproofness exception. ISTM that most of the complication has to be dealt with in either approach? Greetings, Andres Freund
