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

From Bruce Momjian
Subject Re: [HACKERS] NEXTSTEP porting problems
Date
Msg-id 199903151501.KAA13086@candle.pha.pa.us
Whole thread Raw
In response to NEXTSTEP porting problems  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: [HACKERS] NEXTSTEP porting problems
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.


> 
> 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?

--  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
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Odd behavior of type coercion for datetime
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Another speedup idea (two, even)