Skip site navigation (1) Skip section navigation (2)

Post-mortem: Another bug in pg_operator.h

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: scrappy(at)hub(dot)org, maillist(at)candle(dot)pha(dot)pa(dot)us, lockhart(at)alumni(dot)caltech(dot)edu
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Post-mortem: Another bug in pg_operator.h
Date: 1998-10-29 05:26:47
Message-ID: 3749.909638807@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
OK, I have done the deed.  If I blew it, you can back out the last
few commits and then come break my fingers ... but I believe it's
right.

What I found was a boatload of minor typos in operator definitions
for lesser-used types.  (My faith in the analysis procedure is
strengthened by the fact that it didn't gripe about any operators
for the thoroughly-shaken-out types like int4 and float8.)  The
operators I had to change were for these types and combinations:
	int8
	int4 vs. int8, and vice versa
	int2 vs. int4, and vice versa
	bool < bool, bool > bool
	tinterval
	path
	path vs. point
	box vs. point
	float4 vs. float8, and vice versa
	circle vs. point
	lseg

A typical bug is "int48le claims to be the commutator of int48ge,
but it ought to commute with int84ge".  I also saw a lot of confusion
between the commutator and negator roles ... we could do with some
better documentation, I suspect.

The only regression test that changed results was tinterval, which
I already knew was broken.  This says that the coverage of our
regression tests for off-the-beaten-path datatypes is not thorough :-(

Most of the checks I used to find bogus entries are embodied in 
the new regression test opr_sanity --- you can look at that script
to see whether you agree with the conditions I checked.

One thing I'm still a little bothered by is that I don't understand
the difference between the oprlsortop and oprrsortop columns.  In
all the existing tuples that weren't demonstrably bogus, the two
columns have the same value.  What's the point of distinguishing
them, and do the conditions expressed in opr_sanity need refinement?

Note that these changes require an initdb to be effective.  Worse,
there's still one initdb-forcing change to come, namely resolving
which operator really is point @ path.  The opr_sanity regression
test will keep failing until we fix this ;-).  So, the geometric
operator gurus had better get together and decide which it should
be, pronto.

			regards, tom lane

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-10-29 05:33:00
Subject: Re: [HACKERS] 6.4 and reserved word USER...
Previous:From: Thomas G. LockhartDate: 1998-10-29 05:26:07
Subject: Re: [HACKERS] Another bug in pg_operator.h

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group