Re: Making CASE error handling less surprising - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Making CASE error handling less surprising
Date
Msg-id 20200724172616.jatojbcs22bipuf6@alap3.anarazel.de
Whole thread Raw
In response to Re: Making CASE error handling less surprising  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Making CASE error handling less surprising
Next
From: Pavel Stehule
Date:
Subject: Re: Making CASE error handling less surprising