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
