
> > 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.

Andreas

Wed, 27 Jun 2001 13:03:46 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: AW: AW: functions returning records
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


Wed, 27 Jun 2001 07:21:17 -0400 (EDT)
Alex Pilosov <alex@pilosoft.com>
Re: AW: AW: AW: functions returning records