> Joe Conway <[EMAIL PROTECTED]> writes:
>> 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 funct
Joe Conway <[EMAIL PROTECTED]> 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-fu
Tom Lane wrote:
It seems to work 99%, but I'm seeing this failure in the regression
tests:
CREATE FUNCTION getfoo(int) RETURNS int AS 'SELECT $1;' LANGUAGE SQL;
SELECT * FROM getfoo(1) AS t1;
! ERROR: ExecMakeTableFunctionResult: expression is not a function call
which of course happens bec
I've spent today messing with making the planner substitute inline
definitions of simple SQL functions, per the comment in
src/backend/optimizer/util/clauses.c:
* XXX Possible future improvement: if the func is SQL-language, and its
* definition is simply "SELECT expression", we could parse and
