frontend: merge is_const and fold_const (eval)

[BugenZhao]

I think the main issue is that the code logic for determining if an ExprImpl can be constant-folded differs from the actual evaluation process for folding it.

So I'm considering if it's possible to merge is_const and fold_const into a single step, that is:

• Provide another implementation of build_from_prost that rejects any other expressions except for Literal and FunctionCall.

• Call that to build the expression. If there's an error, we say that the expression cannot be folded.

• Call eval_row on the built expression, which will utilize short-circuiting.

Originally posted by @BugenZhao in #15758 (review)

cc @xxchan @st1page @xiangjinwu for discussion

[BugenZhao]

• that rejects any other expressions except for Literal and FunctionCall.

This even seems unnecessary. What about always building the expressions and evaluating it on an empty row, then treat any returned error as "not able to do constant-folding"? The point is that we don't have to care about InputRefs in the expression tree as long as it's short-circuited, like:

select true or (k / 0)::boolean from (values (1)) t(k);

[BugenZhao]

A draft demonstrating the idea: #15777

[xzhseh]

This even seems unnecessary.

I believe this will increase building cost especially when the expression takes a relatively long time to build, narrowing down the types of expressions to build at the beginning (e.g., only from Literal or FunctionCall) sounds a good idea.

[BugenZhao]

increase building cost especially when the expression takes a relatively long time to build

Does it sound like this, but have we verified it (for example, through flamegraph)? I'm unsure if this overhead is non-negligible.

[github-actions]

This issue has been open for 60 days with no activity. Could you please update the status? Feel free to continue discussion or close as not planned.