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 about a restriction like
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 in a temp file anyhow.
> As things
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 reflection of your gen
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 a lot of notational h
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
just a compromise
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 in my mind.
Yea