Re: Making CASE error handling less surprising

Hi,

On 2020-07-23 16:56:44 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Hm. Would SQL function inlining be a problem? It looks like that just
> > substitutes parameters. Before calling
> > eval_const_expressions_mutator(). So we'd not know not to evaluate such
> > "pseudo constants".  And that'd probably be confusing, especially
> > because it's not exactly obvious when inlining happens.
> 
> Hm, interesting question.  I think it might be all right without any
> further hacking, because the parameters we care about substituting
> would have been handled (or not) before inlining.  But the interactions
> would be ticklish, and surely worthy of a test case or three.

I'm a bit worried about a case like:

SELECT foo(17);
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?

Greetings,

Andres Freund