We no longer have a fallback for machines without working int64

Started by Tom Laneover 16 years ago4 messageshackers
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest
of the system to support such compilers, it's a bit annoying to
have this little detail break it. On the other hand, it's unclear
that anybody still cares. (Other than people running SCO Openserver,
for whom I have little sympathy anyway.)

Thoughts? Is it worth expending any energy on?

regards, tom lane

#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Tom Lane (#1)
Re: We no longer have a fallback for machines without working int64

Tom Lane wrote:

As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest
of the system to support such compilers, it's a bit annoying to
have this little detail break it. On the other hand, it's unclear
that anybody still cares. (Other than people running SCO Openserver,
for whom I have little sympathy anyway.)

Thoughts? Is it worth expending any energy on?

Yeah, I'd say this much:

#ifdef INT64_IS_BUSTED
#error "unsupported platform"
#endif

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

#3David Fetter
david@fetter.org
In reply to: Tom Lane (#1)
Re: We no longer have a fallback for machines without working int64

On Tue, Jan 05, 2010 at 10:47:33AM -0500, Tom Lane wrote:

As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest of
the system to support such compilers, it's a bit annoying to have
this little detail break it. On the other hand, it's unclear that
anybody still cares. (Other than people running SCO Openserver, for
whom I have little sympathy anyway.)

Thoughts?

There was a use case for supporting non-working int64, but reality has
changed.

Is it worth expending any energy on?

Not IMHO.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: David Fetter (#3)
Re: We no longer have a fallback for machines without working int64

David Fetter <david@fetter.org> writes:

On Tue, Jan 05, 2010 at 10:47:33AM -0500, Tom Lane wrote:

As pointed out here
http://archives.postgresql.org/pgsql-general/2010-01/msg00145.php
the current zic code doesn't cope gracefully with lack of working
int64. Considering the trouble we've gone to throughout the rest of
the system to support such compilers, it's a bit annoying to have
this little detail break it. On the other hand, it's unclear that
anybody still cares. (Other than people running SCO Openserver, for
whom I have little sympathy anyway.)

There was a use case for supporting non-working int64, but reality has
changed.

Yeah, maybe it's time to forget about that. If so, we ought to change
configure to spit up if it can't find a working 64-bit type. Failing
much later on with a strange message from zic isn't too acceptable.

I propose doing that in both HEAD and 8.4, since both those branches are
broken for someone with such a compiler.

regards, tom lane