Re: [HACKERS] Timespan_div misbehaving?

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_subeq
828|>> | 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