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

Just to show I'm not completely crazy, here's a more or less
feature-complete patch set for doing $SUBJECT.

Patches 0001-0005 are the same as previously posted, either in
this thread or <22182.1549124950@sss.pgh.pa.us>, but rebased
over the planner header refactoring I committed recently.

Patch 0006 is the new work: it removes all the "special index
operator" cruft from indxpath.c and puts it into planner support
functions.  I need to write (a lot) more about the API specification
for this support request type, but I think the code is pretty much OK.

I'm still dithering about where to put these planner support functions.
0006 drops them into a new file "utils/adt/likesupport.c", but I'm
not sold on that as a final answer.  The LIKE and regex support
functions should share code, but the execution functions for those
are in different files (like.c and regexp.c), so the "put it beside the
execution function" heuristic isn't much help.  Also, those functions
rely on the pattern_fixed_prefix() functionality that's currently in
selfuncs.c.  I'd kind of like to end up with that in the same file
as its callers.  In any case, the network-subset support code need
not stay beside the LIKE/regex functions, but I didn't bother to
find a new home for it yet.

Another thing worth commenting about is that I'd intended to have
all the LIKE/regex functions share one support function, using a
switch on function OID to determine what to do exactly, much as the
existing code used a switch on operator OID.  That crashed and
burned though, because some of those functions have multiple aliases
in pg_proc, but fmgroids.h has a macro for only one of the aliases.
Maybe it's time to do something about that?  The factorization I used
instead, with a separate support function for each pattern-matching
rule, isn't awful; but I can foresee that this won't be a great answer
for all cases.

Barring objections, I hope to push forward and commit this soon.

			regards, tom lane