Re: [HACKERS] Another bug in pg_operator.h

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> This was, um, fruitful.

My *goodness*, that was a good idea.

I have now located and repaired ninety-three distinct bugs in
pg_operator.h, all of the form "operator A has an incorrect com, negate,
or sort link to operator B". Almost none of them required any semantic
analysis to spot --- I found them by looking for conditions like A links
to B but B doesn't link to A, or A claims B is its commutation but B
doesn't have the right input data types to be that, etc.

The tinterval regress test now produces believable results --- ie,
the order in which allegedly-sorted intervals appear actually agrees
with the length of the intervals. I would imagine that we can get
rid of the special-case NetBSD expected output for tinterval, as well.

I will shortly commit these changes (as soon as I finish another
build/regress pass). I will also commit a new regression test script
that looks for all the test conditions that I used to locate these
problems, in hopes that no new bugs of this ilk will creep in.

There is one unfixed bug in pg_operator, which I let go because I didn't
want to make the decision as to what to do with it, but it needs to be
fixed. Namely, there is a conflict between OIDs 512 (on_ppath) and 754
(pt_contained_path), both of which claim to be the implementation of
"point @ path":

DATA(insert OID = 512 ( "@" PGUID 0 b t f 600 602 16 0 0 0 0 on_ppath intltsel intltjoinsel ));

DATA(insert OID = 754 ( "@" PGUID 0 b t f 600 602 16 755 0 0 0 pt_contained_path - - ));

I imagine that which one you actually get is a quasi-random matter...
we need to decide which one is the One True @, and change the oprname
of the other one.

I suggest that it'd be a Good Idea to develop similar check scripts for
the other hand-maintained tables. But I figure I've done enough for one
day...

regards, tom lane