On Fri, Nov 1, 2019 at 1:19 PM Robert Haas <robertmhaas@gmail.com> wrote:
> Yeah! I mean, users who are using only 4-byte or smaller pass-by-value
> quantities will be harmed, especially in cases where they are storing
> a lot of them at the same time (e.g. sorting) and especially if they
> double their space consumption and run out of their very limited
> supply of memory.
I think that you meant treble, not double. You're forgetting about the
palloc() header overhead. ;-)
Doing even slightly serious work on a 32-bit machine is penny wise and
pound foolish. I also believe that we should support minority
platforms reasonably well, including 32-bit platforms, because it's
always a good idea to try to meet people where they are. Your proposal
doesn't seem like it really gives up on that goal.
> Those are all worthwhile considerations and perhaps
> strong arguments against my proposal. But, people using 8-byte
> oughta-be-pass-by-value quantities are certainly being harmed by the
> present system. It's not a black-and-white thing, like, oh, 8-byte
> datums on 32-bit system is awful all the time. Or at least, I don't
> think it is.
Right.
> Yeah, I've had to fight with this multiple times, and so have other
> people. It's a nuisance, and it causes bugs, certainly in draft
> patches, sometimes in committed ones. It's not "free." If it's a cost
> worth paying, ok, but is it?
#ifdef crud is something that we should go out of our way to eliminate
on general principle. All good portable C codebases go to great
lengths to encapsulate platform differences, if necessary by adding a
compatibility layer. One of the worst things about the OpenSSL
codebase is that it makes writing portable code everybody's problem.
--
Peter Geoghegan