From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, <pgsql-ports(at)postgreSQL(dot)org> |
Subject: | Re: Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure |
Date: | 2003-01-29 17:59:30 |
Message-ID: | Pine.LNX.4.44.0301291857050.789-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers pgsql-ports |
Tom Lane writes:
> I think a reasonable choice in cross-compiling situations would be to
> assume int64 works if we have a long long int datatype, but to force use
> of our own snprintf rather than trusting to luck with the platform's.
That's approximately what's happening. Formerly it insisted on doing a
run check to detect the int64 type. Now it does a compile check when
cross-compiling.
For the snprintf format detection we obviously don't have that chance. I
just refactored the code a little and added a cache variable so the
advanced cross-compiling user can override the check with known values.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-29 19:37:23 | pgsql-server/src/backend/executor Tag: REL7_2_ ... |
Previous Message | Tom Lane | 2003-01-29 15:24:57 | pgsql-server/src/backend/executor Tag: REL7_3_ ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-01-29 18:01:37 | Re: Request for qualified column names |
Previous Message | Andrew Dunstan | 2003-01-29 17:54:09 | Re: [mail] Re: Windows Build System |
From | Date | Subject | |
---|---|---|---|
Next Message | sachin | 2003-01-30 09:57:45 | Request for PostgreSql performance and stability data |
Previous Message | Tom Lane | 2003-01-29 01:50:58 | Testing for int64 (was Re: [COMMITTERS] pgsql-server/ /configure /configure.in...) |