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.
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 |