Re: Making CASE error handling less surprising

Andres Freund <andres(at)anarazel(dot)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.

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.

> 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.

regards, tom lane