Re: Removing "long int"-related limit on hash table sizes
| От | ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) |
|---|---|
| Тема | Re: Removing "long int"-related limit on hash table sizes |
| Дата | |
| Msg-id | 87o8aohlll.fsf@wibble.ilmari.org обсуждение исходный текст |
| Ответ на | Re: Removing "long int"-related limit on hash table sizes (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: Removing "long int"-related limit on hash table sizes
|
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2021-Jul-25, Ranier Vilela wrote: > >> > 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. >> > >> I can see 30 matches in the head tree. (grep -d "1024L" *.c) > > grep grep '[0-9]L\>' -- *.[chyl] > shows some more constants. git grep -Eiw '(0x[0-9a-f]+|[0-9]+)U?LL?' -- *.[chyl] gives about a hundred more hits. We also have the (U)INT64CONST() macros, which are about about two thirds as common as the U?LL? suffixes. - ilmari
В списке pgsql-hackers по дате отправления: