Re: custom function for converting human readable sizes to bytes

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: custom function for converting human readable sizes to bytes
Дата
Msg-id CAEZATCXHZ5gGFrfcF9_yw5h6WDxr68qdFiWhvMgFR3ascnQCag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: custom function for converting human readable sizes to bytes  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Ответы Re: custom function for converting human readable sizes to bytes  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Список pgsql-hackers
On 17 February 2016 at 00:39, Vitaly Burovoy <vitaly.burovoy@gmail.com> wrote:
> On 2/16/16, Vitaly Burovoy <vitaly.burovoy@gmail.com> wrote:
>> On 2/16/16, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>>> Fixing that in parse_memory_unit() would be messy because it assumes a
>>> base unit of kB, so it would require a negative multiplier, and
>>> pg_size_bytes() would have to be taught to divide by the magnitude of
>>> negative multipliers in the same way that guc.c does.
>
> Now parse_memory_unit returns -1024 for bytes as divider, constant
> "bytes" has moved there.
> Add new memory_units_bytes_hint which differs from an original
> memory_units_int by "bytes" size unit.
> Allow hintmsg be NULL and if so, skip setting dereferenced variable to
> memory_units_bytes_hint.
>

I think that approach is getting more and more unwieldy, and it simply
isn't worth the effort just to share a few values from the unit
conversion table, especially given that the set of supported units
differs between the two places.


>>> ISTM that it would be far less code, and much simpler and more
>>> readable to just parse the supported units directly in
>>> pg_size_bytes(), rather than trying to share code with guc.c, when the
>>> supported units are actually different and may well diverge further in
>>> the future.
>>

I've gone with this approach and it is indeed far less code, and much
simpler and easier to read. This will also make it easier to
maintain/extend in the future.

I've made a few minor tweaks to the docs, and added a note to make it
clear that the units in these functions work in powers of 2 not 10.

I also took the opportunity to tidy up the number scanning code
somewhat (I was tempted to rip it out entirely, since it feels awfully
close to duplicating the numeric code, but it's probably worth it for
the better error message).

Additionally, note that I replaced strcasecmp() with pg_strcasecmp(),
since AIUI the former is not available on all supported platforms.

Barring objections, and subject to some more testing, I intend to
commit this version.

Regards,
Dean

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rushabh Lathia
Дата:
Сообщение: Re: Should PostgresFDW ImportForeignSchema should import the remote table default expression?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates