Re: 64-bit API for large objects - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: 64-bit API for large objects
Date
Msg-id 20050926212148.GU30974@pervasive.com
Whole thread Raw
In response to Re: 64-bit API for large objects  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 64-bit API for large objects
List pgsql-hackers
On Sat, Sep 24, 2005 at 12:13:11PM -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
> >> For that matter, we can't even guarantee that they work at all: not
> >> all platforms even *have* int64 types.
> 
> > What platforms that PG supports don't have int64 arithmetic?
> 
> We claim to build with any ANSI C compiler, and there is no requirement
> for a 64-bit type in ANSI C.
> 
> The historical project policy is that we should still build without
> such a type, and everything should still work except that the effective
> bounds of bigint data correspond to int32 instead of int64 limits.
> I see no reason to back off that policy.  It's not very much harder
> to do it right.

So what happens if you attempt to put a value greater than 2^32 into a
bigint on a non-int64 platform?

I would argue that by default we should not allow users to even create
bigints on any platform where bigint = int. And if the default is
overridden, we should still throw a warning.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: [PERFORM] A Better External Sort?
Next
From: "Jonah H. Harris"
Date:
Subject: Re: [PERFORM] A Better External Sort?