Re: [HACKERS] Another bug in pg_operator.h

> Actually, the darn thing is *crawling* with bugs.

OK, sit down and take a deep breath. And another one. OK, do you still
see bugs everywhere? Oh, that's too bad. We'll send someone over right
away. Stay away from sharp objects, OK? *grin*

> The comparison operators on booleans, tintervals, and lsegs are all
> pretty seriously busted --- they have incorrect commute and/or negate
> links.  I am worried about what other similar bugs may be in there,
> but short of groveling over the entries by hand, I don't know what 
> else to do to check the table further.

Well, we should grovel over the entries by hand, for v6.5. I'd love to
get that thing cleaned up. But I'll bet that some of what you're
finding, although inconsistant, has no adverse effect currently. And it
isn't worse than in previous releases (and in some places it is better). 

In particular, the commute and negate links are not used as extensively
as you might think they should be. But I'd like them to be used more in
the future.

I vaguely recall that I do (mis-)use the commute operators for entries
for which the commute operator would not otherwise be meaningful to help
reorder expressions in the parser. I think that for mixed-type operators
I use the commute column to suggest an alternate operator when trying to
find candidates in the new type coersion stuff.

> BTW Bruce's fix of this morning wasn't right either --- he misspelled
> the name of the lseg_ne comparison routine.

Well, fix that for sure...

> I am currently running a build and regression test for the attached
> diffs, which I propose to commit if the regress passes.
> I expect to find that this explains the tinterval regression 
> differences I've been seeing.  The tinterval expected file is clearly 
> wrong, because it contains "sorted" lists of tintervals that are 
> obviously not in order.

tinterval is an "orphan" type. If it is really a useful type for people,
we should adopt it and fix it up.

> BTW, is it sufficient to edit pg_operator.h, rebuild, reinstall, and
> initdb?  Or is there some additional incantation that needs to be made
> when patching pg_operator.h?

Not that I can recall. You shouldn't reassign OIDs, and there is a small
chance that an OID you remove is actually referenced in one of the
indexing tables (I don't recall the exact layout). I've found that I
need to do a full "make clean install", otherwise some things end up in
an inconsistant state, probably due to incomplete Makefile dependencies.

> Stop the presses .... looks like int8 and int4-vs-int8 comparators 
> are bogus too ... geez ...

Is this a robust system or what! You can get half the tables wrong and
still get good results. Those AI guys are green with envy :)

btw, what'd I do wrong on those?
                  - Tom