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

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 (view raw or flat)
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

pgsql-hackers by date

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

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