Re: ExecMakeTableFunctionResult vs. pre-evaluated functions

Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> A grotty answer is to not apply constant-expression folding to table
>> function RTE entries. A better answer would be to make
>> ExecMakeTableFunctionResult more flexible, but I'm not quite sure what
>> it should do if presented a non-function-call expression tree. Any
>> thoughts?

> If presented with a non-function-call expression tree, can we always evaluate
> it to produce a scalar constant (if it isn't already)? If so, why not do that,
> create a one row, one column tuplestore, and exit? It's really no different
> than a function call that does the same, is it?

Yeah, that's probably a reasonable approach to take. It would fail if
we had an expression that returned a non-scalar value (viz. a set),
but the constant-folder won't try to fold or inline anything that
returns a set, so you shouldn't see any problem in practice.

We do need to do something about this, since even without the inlining
code there's a problem: the only reason the regression example works in
7.3 is that the constant-simplifier doesn't fire. Which it would, if
the function were marked as immutable, as would be reasonable to do.

regression=# select version();
version
-------------------------------------------------------------
PostgreSQL 7.3 on hppa-hp-hpux10.20, compiled by GCC 2.95.3
(1 row)

regression=# CREATE FUNCTION getfoo(int) RETURNS int AS 'SELECT $1;'
regression-# LANGUAGE SQL immutable;
CREATE FUNCTION
regression=# SELECT * FROM getfoo(1) AS t1;
ERROR: ExecMakeTableFunctionResult: expression is not a function call

regards, tom lane