On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <and...@anarazel.de> wrote: > I think we should start by just removing all uses of long. There's > really no excuse for them today, and a lot of them are bugs waiting to > happen.
I like the idea of banning "long" altogether. It will probably be hard to keep it out of third party code that we vendor-in, or even code that interfaces with libraries in some way, but it should be removed from everything else. It actually doesn't seem particularly hard to do so, based on a quick grep of src/backend/. Most uses of "long" is code that sizes something in local memory, where "long" works for the same reason as it works when calculating the size of a work_mem allocation -- ugly, but correct. A few uses of "long" seem to be real live bugs, albeit bugs that are very unlikely to ever hit. _h_indexbuild() has the same bug as _bt_load(), also due to commit ab0dfc961b6 -- I spotted that in passing when I used grep. > We read from larger files in a few places though. E.g. pg_dump. Most > places really just should use pgoff_t... I wasn't even aware of pgoff_t. It is only used in frontend utilities that I don't know that much about, whereas off_t is used all over the backend code. -- Peter Geoghegan
