What I'm envisioning therefore is that we allow an auxiliary function to be attached to any operator or function that can provide functionality like this, and that we set things up so that the set of tasks that such functions can perform can be extended over time without SQL-level changes. For example, we could say that the function takes a single Node* argument, and that the type of Node tells it what to do, and if it doesn't recognize the type of Node it should just return NULL indicating "use default handling". We'd start out with two relevant Node types, one for the selectivity-estimation case and one for the extract-a-lossy- index-qual case, and we could add more over time.
Does this help with these cases?
* Allow a set returning function to specify number of output rows, in cases where that is variable and dependent upon the input params?
* Allow a normal term to match a functional index, e.g. WHERE x = 'abcdefgh' => WHERE substr(x, 1 , 5) = 'abcde' AND x = 'abcdefgh'
* Allow us to realise that ORDER BY f(x) => ORDER BY x so we can use ordered paths from indexes, or avoid sorts.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
