On Mon, Apr 29, 2019 at 11:10 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > If we don't want to rely on "L" constants then we'll have to write these > cases like "work_mem * (size_t) 1024" which is ugly, lots more keystrokes, > and prone to weird precedence problems unless you throw even more > keystrokes (parentheses) at it. I'm not excited about doing that just > to allow larger work_mem settings on Win64.
I don't think that anybody cares about Win64 very much. Simplifying the code might lead to larger work_mem settings on that platform, but that's not the end goal I have in mind. For me, the end goal is simpler code. > I'm not suggesting that we don't need to fix uses of "long" for tuple > counts, and perhaps other things. But I think getting rid of it in memory > size calculations might be a lot of work for not a lot of reward. Whether or not *fully* banning the use of "long" is something that will simplify the code is debatable. However, we could substantially reduce the use of "long" across the backend without any real downside. The work_mem question can be considered later. Does that seem reasonable? -- Peter Geoghegan
