From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | ExecMakeTableFunctionResult vs. pre-evaluated functions |
Date: | 2002-12-01 06:21:35 |
Message-ID: | 16109.1038723695@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 could parse and substitute
* the expression here. This would avoid much runtime overhead, and perhaps
* expose opportunities for constant-folding within the expression even if
* not all the func's input args are constants. It'd be appropriate to 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 is
regression=# 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 ...
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolai Tufar | 2002-12-01 06:22:55 | Re: Segmentation fault while COPY in 7.3 |
Previous Message | Joe Conway | 2002-12-01 06:15:17 | Re: ALTER TABLE schema SCHEMA TO new_schema? |