Re: custom function for converting human readable sizes to bytes

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Subject: Re: custom function for converting human readable sizes to bytes
Date: 2015-11-23 09:11:44
Message-ID: CADkLM=fSCYg0UAYxx3pZC5zrkYJr5he1NcjHPnjrheSP+Dz42Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 22, 2015 at 11:24 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
> 2015-11-22 23:54 GMT+01:00 Corey Huinker <corey(dot)huinker(at)gmail(dot)com>:
>
>> What about pg_size_unpretty()?
>>>
>> I was going to suggest pg_size_ugly(), but unpretty does emphasize the
>> inverse (rather than opposite) nature of the function.
>>
>
> "unpretty", "ugly" aren't good names
>
> maybe pg_size_bytes or different approach
>
> we can introduce data type - bytesize - default input/output is human
> readable text - and conversion to bigint is implicit
>
> Some like
>
> select .. where pg_table_size(oid) > bytesize '3.5GB'
>
> and instead pg_size_pretty(pg_table_size(oid)) we can write
> pg_table_size(oid)::bytesize
>
> Regards
>
> Pavel
>

+1 to both pg_size_bytes() and ::bytesize. Both contribute to making the
statements more self-documenting.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2015-11-23 09:29:39 Re: onlyvalue aggregate (was: First Aggregate Funtion?)
Previous Message Craig Ringer 2015-11-23 06:34:23 Re: SPI and transactions