I said:
> It looks like the entry for it in pg_proc is right, but the one in
> pg_operator is wrong.
>
> Hmm, a whole new class of cross-checks that opr_sanity ought to make ;-)
Indeed, applying a mechanical cross-check was fruitful ... I found four
dozen pg_operator entries that disagree with the corresponding pg_proc
entries:
QUERY: SELECT p1.oid, p1.oprname, p2.oid, p2.proname
FROM pg_operator AS p1, pg_proc AS p2
WHERE p1.oprcode = p2.oid AND p1.oprkind = 'b' AND (p2.pronargs != 2 OR p1.oprresult != p2.prorettype OR
(p1.oprleft!= p2.proargtypes[0] AND p2.proargtypes[0] != 0) OR (p1.oprright != p2.proargtypes[1] AND
p2.proargtypes[1]!= 0));oid|oprname| oid|proname
----+-------+----+------------- 15|= | 852|int48eq 36|<> | 853|int48ne 37|< | 854|int48lt
76|> | 855|int48gt 80|<= | 856|int48le 82|>= | 857|int48ge 532|= | 158|int24eq
533|= | 159|int42eq 534|< | 160|int24lt 535|< | 161|int42lt 536|> | 162|int24gt
537|> | 163|int42gt 538|<> | 164|int24ne 539|<> | 165|int42ne 540|<= | 166|int24le
541|<= | 167|int42le 542|>= | 168|int24ge 543|>= | 169|int42ge 609|< | 66|int4lt
610|> | 147|int4gt 611|<= | 149|int4le 612|>= | 150|int4ge 626|!!= |1285|int4notin
974||| |1258|textcat 979||| |1258|textcat
1055|~ |1254|textregexeq
1056|!~ |1256|textregexne
1063|~ |1254|textregexeq
1064|!~ |1256|textregexne
1211|~~ | 850|textlike
1212|!~~ | 851|textnlike
1213|~~ | 850|textlike
1214|!~~ | 851|textnlike
1232|~* |1238|texticregexeq
1233|!~* |1239|texticregexne
1234|~* |1238|texticregexeq
1235|!~* |1239|texticregexne
1522|<-> |1476|dist_pc
1585|/ |1326|timespan_div 820|= | 920|network_eq 821|<> | 925|network_ne 822|< | 921|network_lt
823|<= | 922|network_le 824|> | 923|network_gt 825|>= | 924|network_ge 826|<< | 927|network_sub
827|<<= | 928|network_subeq828|>> | 929|network_sup
1004|>>= | 930|network_supeq
(49 rows)
Some of these are quasi-legitimate cases (like both "text" and "varchar"
entries for one operator --- is that really necessary?). Quite a few
seem to be real bugs. Working on fixing them now.
If I can figure out how to deal with the binary-equivalent cases
automatically, will commit an extension of opr_sanity regress test to
detect such mistakes in future.
regards, tom lane