Given this basic SQL statement:
select * from table where col = function() ;
There are three basic types of SQL behaviors that should be able to be
performed.
(1) "function()" returns a single value. Postgres should be able to
understand how to optimize this to be: "select * from table where col =
value" where value is the datum returned by function.
(2) "function()" returns a number of values that are independent of the
query. Postgres should be able to optimize this to be: "select * from
table where col in (val1, val2, val3, ..valn)." I guess Postgres can
loop until done, using the isDone flag?
(3) "function()" returns a value based on the query. (This seems to be
how it currently functions.) where "select * from table where col =
function()" will end up doing a full table scan.
(1) and (2) are related, and could probably be implemented using the
same code.
(3) Seems to be how Postgres is currently optimized.
It seems like Tom Lane laid the foundation for this behavior in 7.1
newC. (Does it now work this way?)
Does anyone see a problem with this thinking, and does it make sense to
attempt this for 7.2? I am looking into the function manager stuff to
see what would be involved.
--
http://www.mohawksoft.com
