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

From Vitaly Burovoy
Subject Re: custom function for converting human readable sizes to bytes
Date
Msg-id CAKOSWNn6gBPBAH-CiyWJ2w+L4C3ekK7b7-gp+y-gssDDw7A5iA@mail.gmail.com
Whole thread Raw
In response to Re: custom function for converting human readable sizes to bytes  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: custom function for converting human readable sizes to bytes
Re: custom function for converting human readable sizes to bytes
List pgsql-hackers
On 2/10/16, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hi Vitaly,
>
> please, can you send your version of this patch, how we talked about it in
> Moscow?
>
> Thank you
>
> Pavel

Hello, Pavel!

Please find attached my version of the patch (it applies cleanly on
top of 64d89a9 which is current master).

It is time to change oid. 3331 is used by "bytea_sortsupport", I set
3334 to "pg_size_bytes".

I got a code design of numbers checking from json_lex_number in
src/backend/utils/adt/json.c
For me it seems more structured. I adapted it a little and it allows
to add parsing an exponent (like '10е3 Mb') easily for full support of
numeric (if sometimes it is necessary).

When I added "trimming" for size units (playing with avoiding an extra
buffer), I found there is easy to support "bytes" unit (but "byte" is
still unsupported).


Also this version includes all changes I mentioned in my last review[1]:
1. parse_memory_unit returns value instead of using a pointer (return
zero if noting is found) for it;
2. all messages are in a single style (nuances are in errdetails);
3. "select"s are in uppercase, rephrased and moved a comment block in test;
4. several tests are added (also with supporting of "bytes" unit);
5. a sentence in a documentation is rephrased (numeric->fixed-point
number); "bytes" unit is added to both functions;
6. fixed indentation a little;
7. pfree is removed (it is easier than removing all other allocated resources).


I still think my changes are little and they are based on your work
(and research).

[1]http://www.postgresql.org/message-id/CAKOSWNk13WVDem06LRo-HucR0pR6Et29+dvqY6J5sKxzarUbRw@mail.gmail.com

--
Best regards,
Vitaly Burovoy

Attachment

pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Mac OS: invalid byte sequence for encoding "UTF8"
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: function parse_ident