Re: Removing "long int"-related limit on hash table sizes
От | Tom Lane |
---|---|
Тема | Re: Removing "long int"-related limit on hash table sizes |
Дата | |
Msg-id | 173245.1627239196@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Removing "long int"-related limit on hash table sizes (Ranier Vilela <ranier.vf@gmail.com>) |
Ответы |
Re: Removing "long int"-related limit on hash table sizes
|
Список | pgsql-hackers |
Ranier Vilela <ranier.vf@gmail.com> writes: > I think int64 is in most cases the counterpart of *long* on Windows. I'm not particularly on board with s/long/int64/g as a universal solution. I think that most of these usages are concerned with memory sizes and would be better off as "size_t". We might need int64 in places where we're concerned with sums of memory usage across processes, or where the value needs to be allowed to be negative. So it'll take case-by-case analysis to do it right. BTW, one aspect of this that I'm unsure how to tackle is the common usage of "L" constants; in particular, "work_mem * 1024L" is a really common idiom that we'll need to get rid of. Not sure that grep will be a useful aid for finding those. regards, tom lane
В списке pgsql-hackers по дате отправления: