On Fri, Jul 24, 2020 at 1:18 PM Tom Lane wrote:
> The real bottom line is: if you don't want to do this, how else do
> you want to fix the problem? I'm no longer willing to deny that
> there is a problem.
That's the wrong question. The right question is whether we're
sufficiently certain that a
On Sun, Jul 26, 2020 at 1:27 PM Chris Travers wrote:
> The first (probably the best) would be a solution along the lines of yours
> along with a session-level GUC variable which could determine whether case
> branches can fold constants.
Bluntly, that seems like a terrible idea. It's great if y
On Fri, Jul 24, 2020 at 7:18 PM Tom Lane wrote:
> Robert Haas writes:
> > Like Pavel, and I think implicitly Dagfinn and Andres, I'm not sure I
> > believe this. Pavel's example is a good one. The leakproof exception
> > helps, but it doesn't cover everything. Users I've encountered throw
> > th
pá 24. 7. 2020 v 19:46 odesílatel Tom Lane napsal:
> Andres Freund writes:
> > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > that involve only "proper" constants continue to get evaluated even
> > within CASE, largely address that?
>
> The more I think about that the
Andres Freund writes:
> Wouldn't the rule that I proposed earlier, namely that sub-expressions
> that involve only "proper" constants continue to get evaluated even
> within CASE, largely address that?
The more I think about that the less I like it. It'd make the behavior
even harder to reason a
On July 24, 2020 10:30:37 AM PDT, Pavel Stehule wrote:
>pá 24. 7. 2020 v 19:13 odesílatel Andres Freund
>napsal:
>> Your earlier example of a WHEN ... THEN upper('constant') ... would
>> still have the upper('constant') be evaluated, because it doesn't
>> involve a parameter. And e.g. THEN upp
pá 24. 7. 2020 v 19:13 odesílatel Andres Freund napsal:
> Hi,
>
> On 2020-07-24 19:03:30 +0200, Pavel Stehule wrote:
> > pá 24. 7. 2020 v 18:49 odesílatel Andres Freund
> napsal:
> > > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > > that involve only "proper" constan
Hi,
On 2020-07-23 22:34:53 -0400, Tom Lane wrote:
> Andres Freund 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 ye
Robert Haas writes:
> Like Pavel, and I think implicitly Dagfinn and Andres, I'm not sure I
> believe this. Pavel's example is a good one. The leakproof exception
> helps, but it doesn't cover everything. Users I've encountered throw
> things like date_trunc() and lpad() into SQL code and expect t
Hi,
On 2020-07-24 19:03:30 +0200, Pavel Stehule wrote:
> pá 24. 7. 2020 v 18:49 odesílatel Andres Freund napsal:
> > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > that involve only "proper" constants continue to get evaluated even
> > within CASE, largely address that
pá 24. 7. 2020 v 18:49 odesílatel Andres Freund napsal:
> Hi,
>
> On 2020-07-24 12:31:05 -0400, Robert Haas wrote:
> > On Thu, Jul 23, 2020 at 12:57 PM Tom Lane wrote:
> > > Every so often we get a complaint like [1] about how a CASE should have
> > > prevented a run-time error and didn't, becau
Hi,
On 2020-07-24 12:31:05 -0400, Robert Haas wrote:
> On Thu, Jul 23, 2020 at 12:57 PM Tom Lane wrote:
> > Every so often we get a complaint like [1] about how a CASE should have
> > prevented a run-time error and didn't, because constant-folding tried
> > to evaluate a subexpression that would
On Thu, Jul 23, 2020 at 12:57 PM Tom Lane wrote:
> Every so often we get a complaint like [1] about how a CASE should have
> prevented a run-time error and didn't, because constant-folding tried
> to evaluate a subexpression that would not have been entered at run-time.
Yes, I've heard such compl
I wrote:
> 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.
He
On Fri, Jul 24, 2020 at 4:35 AM Tom Lane wrote:
> Andres Freund 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(
Andres Freund 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 paramet
Hi,
On 2020-07-23 16:56:44 -0400, Tom Lane wrote:
> Andres Freund 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 t
Andres Freund 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 ex
Hi,
On 2020-07-23 13:42:08 -0700, Andres Freund wrote:
> On 2020-07-23 16:34:25 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > 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
Hi,
On 2020-07-23 16:34:25 -0400, Tom Lane wrote:
> Andres Freund 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
>
Andres Freund 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
Andres Freund writes:
> Is there any concern about having to do additional lookups for
> leakproofness? It doesn't seem likely to me since we already need to do
> lookups for the FmgrInfo?
No, we could easily fix it so that one syscache lookup gets both
the provolatile and proleakproof markings.
Hi,
On 2020-07-23 21:56:26 +0200, Pavel Stehule wrote:
> I am afraid of a performance impact.
>
> lot of people expects constant folding everywhere now and I can imagine
> query like
>
> SELECT CASE col1 WHEN 1 THEN upper('hello') ELSE upper('bye') END FROM ...
>
> Now, it is optimized well, b
čt 23. 7. 2020 v 21:56 odesílatel Pavel Stehule
napsal:
>
>
> čt 23. 7. 2020 v 21:43 odesílatel Tom Lane napsal:
>
>> Andres Freund writes:
>> > On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
>> >> Would it be feasible to set up an exception handler when constant-
>> >> folding c
Hi,
On 2020-07-23 15:43:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
> >> Would it be feasible to set up an exception handler when constant-
> >> folding cases that might not be reached, and leave the expression
> >> unfolded
čt 23. 7. 2020 v 21:43 odesílatel Tom Lane napsal:
> Andres Freund writes:
> > On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
> >> Would it be feasible to set up an exception handler when constant-
> >> folding cases that might not be reached, and leave the expression
> >> unfolde
Andres Freund writes:
> On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
>> Would it be feasible to set up an exception handler when constant-
>> folding cases that might not be reached, and leave the expression
>> unfolded only if an error was thrown, or does that have too much
>> ov
Hi,
On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
> > Every so often we get a complaint like [1] about how a CASE should have
> > prevented a run-time error and didn't, because constant-folding tried
> > to evaluate a subexpression that would not have been en
Tom Lane writes:
> Every so often we get a complaint like [1] about how a CASE should have
> prevented a run-time error and didn't, because constant-folding tried
> to evaluate a subexpression that would not have been entered at run-time.
>
> It struck me that it would not be hard to improve this
Every so often we get a complaint like [1] about how a CASE should have
prevented a run-time error and didn't, because constant-folding tried
to evaluate a subexpression that would not have been entered at run-time.
It struck me that it would not be hard to improve this situation a great
deal. If
30 matches
Mail list logo
