On Wed, Oct 31, 2018 at 9:19 AM Tomas Vondra <tomas.von...@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
