Re: BUG #12644: Planner fails to use available index with anything other than default operator

Jim McDonald <Jim(at)mcdee(dot)net> writes:
> On 24/01/2015 15:01, Tom Lane wrote:
>> Nope, this doesn't work, never has, and will not in the foreseeable
>> future. Index access is defined in terms of operators, not other
>> ways to access the same function; see

> Fair enough. As a workaround in the meantime is it possible to create a
> custom operator that is recognised as being in the correct family/class
> so that it will use the index?

Not really, I'm afraid. In the abstract maybe you could add such an
operator to an existing operator class; but in practice this will fall
foul of the unique indexes on pg_amop, which insist that there be
at most one operator per strategy per opclass.

However, there's more than one way to skin a cat. I think you could
probably define such an operator that references an inlineable SQL
function that expands to the desired underlying operator, along the
lines of

create function my_jsonb_exists(jsonb, text) returns bool as
'select $1 ? $2' language sql immutable;

create operator ### ( procedure = my_jsonb_exists, ...

regards, tom lane