Horton

Re: custom function for converting human readable sizes to bytes

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>, Corey Huinker <corey.huinker@gmail.com>, Guillaume Lelarge <guillaume@lelarge.info>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2015-11-23T17:31:19Z
Lists: 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
>

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)