ExecMakeTableFunctionResult vs. pre-evaluated functions
От | Tom Lane |
---|---|
Тема | ExecMakeTableFunctionResult vs. pre-evaluated functions |
Дата | |
Msg-id | 16109.1038723695@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: ExecMakeTableFunctionResult vs. pre-evaluated functions
|
Список | pgsql-hackers |
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 couldparse and substitute* the expression here. This would avoid much runtime overhead, and perhaps* expose opportunitiesfor constant-folding within the expression even if* not all the func's input args are constants. It'd be appropriateto do* that here, not in the parser, since we wouldn't want it to happen until* after rule substitution/rewriting. 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? regards, tom lane PS: another little problem isregression=# explain SELECT * FROM getfoo(1) AS t1;server closed the connection unexpectedly but I'm sure that's just a lack of flexibility in explain.c ...
В списке pgsql-hackers по дате отправления: