At Wed, 15 Apr 2020 18:17:30 -0700, Elvis Pranskevichus <elprans@gmail.com> wrote in
> On Wednesday, April 15, 2020 5:14:05 P.M. PDT Tom Lane wrote:
>
> > In point of fact, there are many ways in which CASE and related
> > constructs fail to guarantee evaluation order, as noted in
> > https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EX
> > PRESS-EVAL
> >
> > The particular case mentioned there seems to be about the same as
> > here: constant-folding happens even in CASE arms that will never be
> > reached at runtime.
>
> Yes, but function arguments aren't constants are they? At least the
> documentation makes no effort to mention that.
>
> > would be quite unhappy with the performance impact of de-optimizing
> > CASE that way.
>
> I'm not arguing for the general de-optimization for CASE, just for not
> treating arguments of inlined functions as constants in the CASE
> statement. For arguments of a prepared statement this optimization
> makes even less sense.
Perhaps there's seems to be no nice way to detect the case where an
arm in a case expression cannot even be executed although the
expression is seemingly constant-foldable. (Note that all arms of the
case has a chance to be reached since the case-expression is NOT a
constant at the parse time.) Isn't there any workaround usable for
you? I'm not sure what is your real issue, but it seems to me
unnatural that the first argument of intfmt is a literal string.
For example, the following query works.
SELECT
intfmt(q.data, q.fmt) AS "out"
FROM
(SELECT
("v" = first_value("v") OVER ()),
'123,456' AS data, '999,999' AS fmt
FROM
(SELECT 1 AS "v") AS "q2"
) AS "q";
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center