Re: Allowing extensions to supply operator-/function-specific info

On Sun, 20 Jan 2019 at 23:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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