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 CAFj8pRAuupw3JwBZiXB0L98GfTD1xV2E4gmDTVhf9a=pOgvCRQ@mail.gmail.com
Whole thread Raw
In response to Re: custom function for converting human readable sizes to bytes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: custom function for converting human readable sizes to bytes  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: custom function for converting human readable sizes to bytes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers


2015-11-23 18:04 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 11/23/15 3:11 AM, Corey Huinker wrote:
>> +1 to both pg_size_bytes() and ::bytesize. Both contribute to making the
>> statements more self-documenting.

> The function seems like overkill to me if we have the type. Just my
> opinion though. I'm thinking the type could just be called 'size' too
> (or prettysize?). No reason it has to be tied to bytes (in particular
> this would work for bits too).

Please, no.  That's *way* too generic a name.

I do not actually agree with making a type for this anyway.  I can
tolerate a function, but adding a datatype is overkill; and it will
introduce far more definitional issues than it's worth.  (eg, which
other types should have casts to/from it, and at what level)

so pg_size_bytes is good enough for everybody?

Regards

Pavel
 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Declarative partitioning
Next
From: Robert Haas
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual