Re: custom function for converting human readable sizes to bytes

Dean Rasheed <dean.a.rasheed@gmail.com>

From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Vitaly Burovoy <vitaly.burovoy@gmail.com>, "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>, Robert Haas <robertmhaas@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jim Nasby <Jim.Nasby@bluetreble.com>, Corey Huinker <corey.huinker@gmail.com>, Guillaume Lelarge <guillaume@lelarge.info>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2016-02-15T09:16:35Z
Lists: pgsql-hackers
> On 12/02/16 10:19, Dean Rasheed wrote:
>> This seems like a reasonable first patch for me as a committer, so
>> I'll take it unless anyone else was planning to do so.
>

So looking at this, it seems that for the most part pg_size_bytes()
will parse any output produced by pg_size_pretty(). The exception is
that there are 2 versions of pg_size_pretty(), one that takes bigint
and one that takes numeric, whereas pg_size_bytes() returns bigint, so
it can't handle all inputs. Is there any reason not to make
pg_size_bytes() return numeric?

It would still be compatible with the example use cases, but it would
be a better inverse of both variants of pg_size_pretty() and would be
more future-proof. It already works internally using numeric, so it's
a trivial change to make now, but impossible to change in the future
without introducing a new function with a different name, which is
messy.

Thoughts?

Regards,
Dean


Commits

  1. Add pg_size_bytes() to parse human-readable size strings.

  2. Refactor check_functional_grouping() to use get_primary_key_attnos().

  3. Correct comment in GetConflictingVirtualXIDs()

  4. Make extract() do something more reasonable with infinite datetimes.

  5. pg_size_pretty: Format negative values similar to positive ones.

  6. pg_size_pretty(numeric)