> 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 - - ));
Yep. I have removed the entry. It didn't even look like it belonged
there.
>
> 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.
That is an amazing way to find a bad pg_operator entry.
>
> 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...
I have done the dirty deed, so Marc can break my fingers.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026