Re: int8 & INT64_IS_BUSTED - Mailing list pgsql-hackers

From Tom Lane
Subject Re: int8 & INT64_IS_BUSTED
Date
Msg-id 12291.1188427412@sss.pgh.pa.us
Whole thread Raw
In response to int8 & INT64_IS_BUSTED  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: int8 & INT64_IS_BUSTED  ("Florian G. Pflug" <fgp@phlo.org>)
List pgsql-hackers
"Florian G. Pflug" <fgp@phlo.org> writes:
> I'm confused about whether int8s work on a machine on which
> INT64_IS_BUSTED. My reading of the code suggests that int8
> will be available, but be, well, busted in such a machine.

The datatype exists, but it's really only int32.

> For example, int8mul seems as if I'd just return the wrong
> answer on such a machine.

Well, obviously it's gonna overflow sooner than you'd think, but it will
give valid answers as long as you never try to compute a value that
doesn't fit in int32; and it will correctly complain if you do.

> Or are platforms with INT64_IS_BUSTED no longer supported,
> and are all those #ifdefs only legacy code?

There are people around here who think it's all useless legacy code,
but I'm not prepared to agree quite yet.  My position is that all the
core functionality should still work if INT64_IS_BUSTED.  You'll see
a surprisingly limited range for bigint, and pgstat counters will
overflow sooner than they otherwise would, and some other noncritical
problems.  But the database still works.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Albert Cervera i Areny
Date:
Subject: Re: Contrib modules documentation online
Next
From: Tom Lane
Date:
Subject: Re: text search function renaming