On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
>> On 16 February 2016 at 05:01, Pavel Stehule <pavel.steh...@gmail.com>
>>> 2016-02-15 10:16 GMT+01:00 Dean Rasheed <dean.a.rash...@gmail.com>:
>> 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.
Well... pg_size_bytes already knows what negative multiplier is (see
the constant skip_unit), but it seems it is hard to teach other
functions expecting values in KB to understand negative multipliers as
> I guess the best way is to simply make "bytes" a valid size unit even
> in GUC by adding it to the memory_unit_conversion_table
Oops. I forgot they are not in bytes.
> with reflecting it in memory_units_hint and removing
> an extra checking from pg_size_bytes.
>> 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.
Initially it was not shared with guc.c and now it is by the letter
of Oleksandr Shulgin and Robert Haas.
I guess since parse_memory_unit uses memory_unit_conversion_table
where values (not for GUC_UNIT_KB but nevertheless) can be negatives
and for KB it can be a single value (-1024), move "bytes" check to
parse_memory_unit, add a constant memory_units_bytes_hint as
copy-paste with included "bytes" size unit (and with a comment it is
special for parse_memory_unit function).
Also change "skip_unit" in dbsize.c to -1024.
>> I'll try to hack something up, and see what it looks like.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: