Dave Cramer <pg@fastcrypt.com> writes:
> Back to the issue at hand. Does anyone have a recommendation for a
> replacement operator besides ?
The bikeshedding potential here might be the worst part of the whole
thing. Still, if we can agree on reasonable substitute names, I wouldn't
be against it, even with the huge lead time in mind.
> When I first noticed this one thought was to create duplicate operators
> specifically for the use of the JDBC driver.
> I had dismissed this at the time, now I'm not so sure
If you mean fixing the problem with an extension that adds replacement
operators without any core code changes, I'm afraid probably not.
It would work okay for operators that are not indexable, but not for
those that can be indexed. (I think only a couple of the existing problem
operators are indexable, but that's enough to make the idea not fly.)
The difficulty with indexable operators is that there is no provision for
multiple operators sharing the same strategy "slot" in an opclass. So
the only way to add additional operators to an opclass is to give them
new strategy numbers, which requires teaching the opclass' support
functions to know about those numbers. This would be just a minor change
(add some case labels) but it *is* a change in the core code.
regards, tom lane