Re: int8 & INT64_IS_BUSTED

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: int8 & INT64_IS_BUSTED
Date: 2007-08-29 22:43:32
Message-ID: 12291.1188427412@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Florian G. Pflug" <fgp(at)phlo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-08-29 22:45:57 Re: text search function renaming
Previous Message Albert Cervera i Areny 2007-08-29 22:37:31 Re: [HACKERS] Contrib modules documentation online