Re: [HACKERS] NEXTSTEP porting problems - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] NEXTSTEP porting problems
Date
Msg-id 199903160129.KAA08433@srapc451.sra.co.jp
Whole thread Raw
In response to Re: [HACKERS] NEXTSTEP porting problems  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
>> A NEXTSTEP3.3 user reported some porting problems.
>> 
>> 1. #if FALSE problem
>> 
>> For example in src/include/utils/int8.h:
>> 
>>     #if FALSE
>>     extern int64 *int28 (int16 val);
>>     extern int16 int82(int64 * val);
>>     
>>     #endif
>> 
>> Unfortunately in NEXTSTEP FALSE has been already defined as:
>> 
>>     #define    FALSE    ((boolean_t) 0)
>> 
>> What about using #if 0 or #if PG_FALSE or whatever instead of #if
>> FALSE?
>> 
>
>Done, by you, I think.

Yes. Marc has applied my patch.

>> 2. Datum problem
>> 
>> NEXTSTEP has its own "Datum" type and of course it coflicts with
>> PostgreSQL's Datum. Possible solution might be put below into c.h:
>> 
>> #ifdef NeXT
>> #undef Datum
>> #define Datum           PG_Datum
>> #define DatumPtr        PG_DatumPtr
>> #endif
>> 
>> 
>> Comments?
>
>Is Datum a #define on NextStep. Can we just #undef it?

I will ask the NextStep user.
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: "Tim Perdue"
Date:
Subject: Re: [HACKERS] "CANNOT EXTEND" -
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] inet data type regression test fails