Re: No = operator for opfamily 426

Manuel Rigger <rigger.manuel@gmail.com> writes:
> Consider the following statements:

> CREATE TABLE t0(c0 TEXT);
> CREATE INDEX i0 ON t0(c0 bpchar_ops);
> SELECT * FROM t0 WHERE t0.c0 LIKE ''; -- ERROR:  no = operator for opfamily 426

Hm.  Right offhand, I'm wondering why we don't reject that index
specification.  I guess it's because we can use the index for
weird cases like

regression=# explain SELECT * FROM t0 WHERE t0.c0::bpchar = '';
                           QUERY PLAN                            
-----------------------------------------------------------------
 Bitmap Heap Scan on t0  (cost=4.21..14.35 rows=7 width=32)
   Recheck Cond: ((c0)::bpchar = ''::bpchar)
   ->  Bitmap Index Scan on i0  (cost=0.00..4.21 rows=7 width=0)
         Index Cond: ((c0)::bpchar = ''::bpchar)
(4 rows)

and even

regression=# explain SELECT * FROM t0 WHERE t0.c0::bpchar like '';
                           QUERY PLAN                            
-----------------------------------------------------------------
 Bitmap Heap Scan on t0  (cost=4.21..14.35 rows=7 width=32)
   Filter: ((c0)::bpchar ~~ ''::text)
   ->  Bitmap Index Scan on i0  (cost=0.00..4.21 rows=7 width=0)
         Index Cond: ((c0)::bpchar = ''::bpchar)
(4 rows)

Really what the error is showing is that like_support.c is being too
aggressive by assuming that it'll necessarily find a matching opfamily
member.  It should probably just silently fail if it can't construct
the opclause it wants.

			regards, tom lane