On Sun, 20 Jan 2019 at 23:48, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
