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

Re: [HACKERS] Platforms with v6.3 trouble

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Bill(dot)Allie(at)mug(dot)org
Cc: lockhart(at)alumni(dot)caltech(dot)edu, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Platforms with v6.3 trouble
Date: 1998-02-27 05:14:05
Message-ID: 199802270514.AAA26463@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> 
> On the SCO UNIXWARE (UNIVEL) port, it is only necessary to replace the macro 
> definition of fastgetattr with a static function in heapam.h in order to get 
> the code to compile.  I guess the people who wrote the compile could not 
> concieve of anyone nesting the trinary operator (?:) to such a depth :-).  The 
> UNIXWARE compiler does an excellent job of in-lining the function on it's own 
> without the macro.  The patch for the version of heapam.h I am using follows 
> (I am currently using USE_UNIVEL_CC_ASM as the trigger, but that can be 
> changed).
> 
> Bruce,  will this change work?  I am not as familiar with this section of code 
> as I would like to be.

This is fine, and a good place to put it, though the port-specific
change should go AFTER the standard #define, not before it, so you do:

#if !defined(SCO)
#define
#else
static ...
#endif

As far as them never suspecting such a macro, well, I never suspected I
would ever write such a macro either.  But I did, and it works.  I
didn't inline this in the first pass of inlining because it looked so
hard, but when I realized how many times it was called, and that I could
inline just the beginning of the function to get more speed when the
cache offset was active, I did it.  The new macro formatting style is my
idea too, and it makes things much simpler.  Look at the ugly
heap_getattr() macros in 6.2.


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

In response to

pgsql-hackers by date

Next:From: Vadim B. MikheevDate: 1998-02-27 05:15:21
Subject: Re: [HACKERS] INT2OID, etc.
Previous:From: Billy G. AllieDate: 1998-02-27 04:46:47
Subject: Re: [HACKERS] Platforms with v6.3 trouble

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