On Fri, Nov 1, 2019 at 1:19 PM Robert Haas <robertmh...@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
