Re: [PATCH] expand the units that pg_size_pretty supports on output

On Thu, 8 Jul 2021 at 01:32, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Hmm, this looked easy, but...
>
> It occurred to me that there ought to be regression tests for the edge
> cases where it steps from one unit to the next. So, in the style of
> the existing regression tests, I tried the following:
>
> SELECT size, pg_size_pretty(size), pg_size_pretty(-1 * size) FROM
> (VALUES (10239::bigint), (10240::bigint),
> (10485247::bigint), (10485248::bigint),
> (10736893951::bigint), (10736893952::bigint),
> (10994579406847::bigint), (10994579406848::bigint),
> (11258449312612351::bigint), (11258449312612352::bigint)) x(size);

> 11258449312612352 | 10240 TB | -10239 TB

Hmm, yeah, I noticed that pg_size_pretty(bigint) vs
pg_size_pretty(numeric) didn't always match when I was testing this
patch, but I was more focused on having my results matching the
unpatched version than I was with making sure bigint and numeric
matched.

I imagine this must date back to 8a1fab36ab. Do you feel like it's
something this patch should fix? I was mostly hoping to keep this
patch about rewriting the code to both make it easier to add new units
and also to make it easier to keep all 3 functions in sync.

It feels like if we're going to fix this negative rounding thing then
we should maybe do it and backpatch a fix then rebase this work on top
of that.

What are your thoughts?

David