Hi,
On 2020-07-23 22:34:53 -0400, Tom Lane wrote:
> Andres Freund <andres@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