From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] NEXTSTEP porting problems |
Date: | 1999-03-16 01:29:01 |
Message-ID: | 199903160129.KAA08433@srapc451.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 1999-03-16 01:35:04 | Re: [HACKERS] inet data type regression test fails |
Previous Message | Tim Perdue | 1999-03-16 01:25:58 | Re: [HACKERS] "CANNOT EXTEND" - |