> I have checked in fixes for all of the genuine bugs that I found in
> pg_operator and pg_proc by means of mechanical consistency checks.
> I would like to add these consistency checks to the regression tests,
> but right now they still produce some bogus "failures":
<snip results>
> All of these mismatches occur because pg_operator contains more than
> one entry for each of the underlying procs. For example, oid 974
> is the operator for "bpchar || bpchar", which is implemented by
> the same proc as "text || text". That's OK because the two types are
> binary-compatible. But there's no good way for an automated test to
> know that it's OK.
> I see a couple of different ways to deal with this:
> 1. Drop all of the above pg_operator entries. They are all redundant
> anyway, given that in each case the data types named by the operator
> are considered binary-compatible with those named by the underlying
> proc. If these entries were not present, the parser would still find
> the operator, it'd just match against the pg_operator entry that names
> the underlying type.
Just a comment: types which are brute-force allowed to be binary
compatible (brute-force because it is compiled into the code rather
than entered into a table) would not be handled exactly the same as if
there were an explicit entry for them. With explicit entries there is
an exact match on for the operator found by the parser on its first
try. With binary compatibility but no explicit entry then the parser
tries first for that explicit match, fails, and then tries some
heuristics to get a good alternative. I would think that for anything
other than *very* small queries and tables the extra time would be
negligible.
> 3. Extend the pg_type catalog to provide info about binary
> compatibility of different types, so that the opr_sanity regress test
> could discover whether a type mismatch is really a problem or not.
This is the elegant solution of course, and probably a lot of work :)
- Tom