As long as we're doing last-minute changes that force initdb ...
I believe I've just identified another error in pg_operator.h.
Specifically, this tuple is bogus and ought to be deleted:
DATA(insert OID = 619 ( "<" PGUID 0 b t f 704 704 16 0 0 0 0 intervalct - - ));
This tuple defines "<" on tinterval's (type 704 = TINTERVAL) as
being "intervalct", or interval-contained-in. Now that doesn't
make a lot of sense. Furthermore there is already a tuple
that defines "<<" as being intervalct:
DATA(insert OID = 573 ( "<<" PGUID 0 b t f 704 704 16 0 0 0 0 intervalct - - ));
and there is another tuple that defines "<" on tintervals as
being "intervallt":
DATA(insert OID = 813 ( "<" PGUID 0 b t f 704 704 16 813 0 0 0 intervallt - - ));
I found this while trying to track down why the tinterval regression
test fails on HPUX (it produces the right tuples, but in the wrong
sort order ... and unlike the rules case, the select does have an
ORDER BY clause). As far as I can tell from the CVS logs, the bogosity
has been in there for at least a year.
It looks to me like the bogus tuple is masking the correct definition
of "<" and causing tintervals to sort incorrectly. Why this doesn't
happen on many other machines isn't clear, but maybe it has something
to do with the platform-dependency of qsort that we already identified?
Anyway, I'm a rank newbie at hacking this stuff, so I'm not about
to commit this change without asking someone else to check my work.
But if it is indeed wrong, right now seems like a good time to fix it...
regards, tom lane
