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
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 |