From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Making CASE error handling less surprising |
Date: | 2020-07-24 17:26:16 |
Message-ID: | 20200724172616.jatojbcs22bipuf6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-07-23 22:34:53 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-07-24 17:30:37 | Re: Making CASE error handling less surprising |
Previous Message | Tom Lane | 2020-07-24 17:18:16 | Re: Making CASE error handling less surprising |