Re: Int64GetDatum - Mailing list pgsql-general

From John R Pierce
Subject Re: Int64GetDatum
Date
Msg-id 4BCD1B78.3080208@hogranch.com
Whole thread Raw
In response to Re: Int64GetDatum  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Int64GetDatum  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Bruce Momjian wrote:
> Tom Lane wrote:
>
>> John R Pierce <pierce@hogranch.com> writes:
>>
>>> I don't know if the build trees can be structured so the include
>>> directories can be differentiated the same as the bin and lib...
>>>
>> The RPM distributions are able to deal with this without actually
>> differentiating: if you install both 32- and 64-bit RPMs then the
>> overlapping files are the same for both, with pg_config.h being
>> a stub that does this:
>>
>> #if defined(__x86_64__)
>> #include "pg_config_x86_64.h"
>> #elif defined(__i386__)
>> #include "pg_config_i386.h"
>> ... etc ...
>>
>> I don't know if Solaris' package management offers the same ability, but
>> if it does, then it could be handled like that.
>>
>
> Ah, good idea.  Is pg_config.h the only file that varies from 32 to
> 64-bit?
>
>

it *appears* to be here, but I don't have the 64 bit file set to compare
with.  there are definately a couple other files that get generated by
./configure, including ecpg_config.h and another that escapes me at the
moment.

from what all I could tell, nothing in that would be likely to change
between 32 and 64 bit builds on either sparc or x86  (but they might
vary between sparc and x86, or even between completely different PG
builds, like integer vs numeric date)



pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Int64GetDatum
Next
From: Craig Ringer
Date:
Subject: Re: modification time & transaction synchronisation problem