Robert Haas <robertmh...@gmail.com> writes: > 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.
+1. If we're otherwise going to need multiple pg_proc columns, this is a better answer just from the standpoint of avoiding pg_proc bloat: we'd only need to add one OID column. And I concur with your point that we're going to have a really hard time parameterizing the mechanism adequately if there isn't dedicated per-function code. regards, tom lane