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
|
Список | 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 по дате отправления: