Re: ExecMakeTableFunctionResult vs. pre-evaluated functions

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: ExecMakeTableFunctionResult vs. pre-evaluated functions
Дата
Msg-id 3DE9B13F.6010503@joeconway.com
обсуждение исходный текст
Ответ на ExecMakeTableFunctionResult vs. pre-evaluated functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ExecMakeTableFunctionResult vs. pre-evaluated functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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 because the table-function expression has been
> reduced to just a constant "1" by the time the executor sees it.
> 
> 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?

Joe




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: ExecMakeTableFunctionResult vs. pre-evaluated functions
Следующее
От: "Nicolai Tufar"
Дата:
Сообщение: Re: [GENERAL] Segmentation fault while COPY in 7.3