Jakub Wartak <[email protected]> writes:
> I propose simply for now that that if there's consensus to drop the 32-bits
> support,
I do not believe there is any such consensus, and I for one am against it.
What was being discussed in the other thread was dropping some dedicated
code paths for 32-bit arches, which is in line with the general policy
that we've had for awhile of not optimizing for such builds anymore.
But there's a long way from that to "it won't work at all".
> The only trouble I see is that we should probalby excplictly continue to
> provide 32-bit client support (to allow embedded clients/IOT to continue).
Yes, that's one of the good reasons for not dropping it altogether.
*Maybe* there is an argument for not supporting 32-bit servers anymore,
but I don't really buy that. Also, how are you going to test a 32-bit
client build if the server has to be somewhere else? Building
infrastructure to support that would quickly eat up whatever win is
to be had.
regards, tom lane
