Re: [HACKERS] Another bug in pg_operator.h

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Another bug in pg_operator.h
Date: 1998-10-29 04:08:13
Message-ID: 199810290408.XAA03822@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-10-29 04:09:28 Re: [HACKERS] Another bug in pg_operator.h
Previous Message Thomas G. Lockhart 1998-10-29 03:54:06 Re: [HACKERS] Another bug in pg_operator.h