On Sun, Feb 26, 2017 at 9:48 AM, Tom Lane wrote:
> [ shrug... ] If you're excited enough about it to do the work, I won't
> stand in your way. But I don't find it to be a stop-ship issue.
I'll add it to my todo list for Postgres 10.
I think it's worth being consistent
Peter Geoghegan writes:
> On Sun, Feb 26, 2017 at 9:07 AM, Tom Lane wrote:
>> Having said that, I'm not sure it's worth the trouble of changing.
>> The platforms where there's a difference are probably not muscular
>> enough that anyone would ever get past 16TB
On Sun, Feb 26, 2017 at 10:37 PM, Tom Lane wrote:
> Having said that, I'm not sure it's worth the trouble of changing.
> The platforms where there's a difference are probably not muscular
> enough that anyone would ever get past 16TB in a temp file anyhow.
Is this comment a
On Sun, Feb 26, 2017 at 9:07 AM, Tom Lane wrote:
> Yeah. This code is far older than our willingness to assume that every
> platform can support int64, and I'm pretty sure that use of "long" was
> just a compromise to get the widest values we could use portably and
> without
Peter Geoghegan writes:
> logtape.c stores block numbers on disk. These block numbers are
> represented in memory as being of type long.
Yeah. This code is far older than our willingness to assume that every
platform can support int64, and I'm pretty sure that use of "long" was
On Sun, Feb 26, 2017 at 2:44 AM, Peter Geoghegan wrote:
> I tend to be suspicious of use of the type "long" in general, because
> in general one should assume that it is no wider than "int". This
> calls into question why any code that uses "long" didn't just use
> "int", at least
logtape.c stores block numbers on disk. These block numbers are
represented in memory as being of type long. This is why BufFile
clients that use the block-based interface (currently limited to
logtape.c and gistbuildbuffers.c) must live with a specific
limitation, as noted within buffile.c:
/*