From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: No = operator for opfamily 426 |
Date: | 2019-11-19 15:47:34 |
Message-ID: | 8686.1574178454@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Manuel Rigger <rigger(dot)manuel(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-11-19 16:10:59 | Re: initdb SegFault |
Previous Message | Tom Lane | 2019-11-19 15:16:02 | Re: initdb SegFault |