On Wed, Oct 31, 2018 at 9:19 AM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> I think it can't be made just by adding a couple of columns to pg_proc,
> as explained above. A separate catalog mapping procs to opclasses (and
> maybe collations) may be needed. For cases where it depends on the
> actual parameter values (like substr/trim/ltrim) an extra function might
> be needed (something like the selectivity functions for data types).
This kinda reminds me of commit
8f9fe6edce358f7904e0db119416b4d1080a83aa. We needed a way to provide
the planner with knowledge about the behavior of specific functions.
In that case, the specific need was to be able to tell the planner
that a certain function call could be omitted or strength-reduced, and
we did that by having the planner call a function that encoded the
necessary knowledge. Here, we want to evaluate a function call and
see whether it is order preserving, which could depend on a whole
bunch of stuff that isn't easily parameterized by catalog entries, but
could be figured out by a C function written for that purpose. I'm
not really sure how that would work in this case, or whether it's a
good idea, but I thought I'd mention it just in case it's helpful.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
