On Wed, 27 Jun 2001, Zeugswetter Andreas SB wrote:
>
> > > In my setup the function would be hidden by a view.
> > Its a different problem. Functions returning tables do just that, return
> > tables, they won't care just what from that table you need. Exposing
> > pieces of optimizer to your function doesn't seem to me like a great
> > idea...
>
> Ok, I think i need to go into a little more detail to explain.
> My function needs to construct a table from the where condition.
> If no where condition is present the result set would be near infinite
> in size (all possible permutations of all possible field values
> e.g. 2^32 for a table with one int column).
>
> The function answers queries about rows that are not in the table,
> but the result is based on rows that are in the table and computed
> by a neural net.
This is pretty s[l]ick. Unfortunately, SQL doesn't know about
lazy-evaluation for functions, and its kind of a different problem from
one I would like to solve, but I agree, maybe some day, there could be a
[documented] way for an SPI function to peek at the query conditions in
the context it was called from.
It is _probably_ already possible to do that by looking up the execution
stack somehow, but its definitely not a documented way, and you must be
able to extract your information from a (Query *) node...
-alex
