From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: ExecMakeTableFunctionResult vs. pre-evaluated functions |
Date: | 2002-12-01 06:50:39 |
Message-ID: | 3DE9B13F.6010503@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolai Tufar | 2002-12-01 07:32:47 | Re: Segmentation fault while COPY in 7.3 |
Previous Message | Tom Lane | 2002-12-01 06:50:38 | Re: Segmentation fault while COPY in 7.3 |