Hi, On 2020-07-23 16:34:25 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Is there an argument to continue simplifying expressions within case > > when only involving "true" constants even with not leakproof functions, > > but only simplify "pseudo" constants like parameters with leakproof > > functions? I.e CASE WHEN ... THEN 1 / 0 would still raise an error > > during simplification but CASE WHEN ... THEN 1 / $1 wouldn't, because $1 > > is not a real constant (even if PARAM_FLAG_CONST). > > Hmm, interesting idea. That might fix all the practical cases in plpgsql, > but it wouldn't do anything to make the behavior more explainable. Not > sure if we care about that though.
I've probably done too much compiler stuff, but to me it doesn't seem too hard to understand that purely constant expressions may get evaluated unconditionally even when inside a CASE, but everything else won't. The fact that we sometimes optimize params to be essentially constants isn't really exposed to users, so shouldn't be confusing. > If we go this way I'd be inclined to do this instead of, not in addition > to, what I originally proposed. Not sure if that was how you envisioned > it, but I think this is probably sufficient for its purpose and we would > not need any additional lobotomization of const-simplification. Yea, I would assume that we'd not need anything else. I've not thought about the subquery case yet, so perhaps it'd be desirable to do something additional there. > > It doesn't seem like it'd be too hard to implement that, but that it'd > > probably be fairly bulky because we'd need to track more state across > > recursive expression_tree_mutator() calls. > > It wouldn't be any harder than what I posted upthread; it would > just be a different flag getting passed down in the context struct > and getting tested in a different place. Cool. Greetings, Andres Freund
