Re: custom function for converting human readable sizes to bytes - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: custom function for converting human readable sizes to bytes
Date
Msg-id CAFj8pRBSKoh_Zd+gqzUate9760XWX_4agOin5Yh7Z-WBLpMZVQ@mail.gmail.com
Whole thread Raw
In response to Re: custom function for converting human readable sizes to bytes  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Responses Re: custom function for converting human readable sizes to bytes  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
List pgsql-hackers
Hi

2016-01-26 13:48 GMT+01:00 Vitaly Burovoy <vitaly.burovoy@gmail.com>:
Hello, Pavel!

That letter was not a complain against you. I'm sorry if it seems like
that for you.

ok.

It was an intermediate review with several points to be clear for _me_
from experienced hackers, mostly about a code design.

26.01.2016 07:05, Pavel Stehule пишет:
>> pg_proc.h has changed, so the CATALOG_VERSION_NO must be also changed.
> this is not a part of patch - only a commiter knows CATALOG_VERSION_NO
>
CATALOG_VERSION_NO is mentioned for a committer, it is not your fault.

>> III. There is no support of 'bytes' unit, it seems such behavior got
>> majority approval[2].
>
> No, because I have to use the supported units by configuration. The configuration supports only three chars long units. Support for "bytes" was removed, when I removed proprietary unit table.
>
Point "III" is the only for the question "d". Also to collect any
possible features from the thread in one place.

>> V. The documentation lacks a note that the base of the "pg_size_bytes"
>> is 1024 whereas the base of the "pg_size_pretty" is 1000.
>
> It isn't true, base for both are 1024. It was designed when special table was used for pg_size_bytes. But when we share same control table, then is wrong to use different table. The result can be optically different, but semantically same.
>
Oops, I was wrong about a base of pg_size_pretty. It was a morning
after a hard night... 

> negative values is fully supported.
You have mentioned it at least three times before. It is not my new
requirement or a point to your fault, it is an argument for
symmetry/asymmetry of the function.

> support of "bytes" depends on support "bytes" unit by GUC. When "bytes" unit will be supported, then it can be used in pg_size_bytes immediately.
By the way there can be a comparison for a special size unit before
calling parse_memory_unit.

there was more requirements based on original proposal (based in  separated control tables). When I leaved this design, I dropped more requirements and now is little bit hard to distinguish what is related and with. Some features can be added later without any possible compatibility issues in next commit fest or later, and I am searching some good borders for this patch. Now, this border is a shared memory unit control table. And I am trying to hold this border.

I am grateful for review - now this patch is better, and I hope near final stage.

Regards

Pavel


 

> Regards
> Pavel
>
>> [2]http://www.postgresql.org/message-id/CACACo5QW7fFsFfhKsTjtYcP4QF3Oh9zA14SC6Z3DXx2yssJjSw@mail.gmail.com

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench - allow backslash-continuations in custom scripts
Next
From: Michael Paquier
Date:
Subject: Re: pgbench - allow backslash-continuations in custom scripts