Re: Add support for unit "B" to pg_size_pretty()

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add support for unit "B" to pg_size_pretty()
Date: 2023-03-03 11:23:21
Message-ID: CAApHDvrzNF9zARfjNacqCpsFckWA84jt7_qmvYpZjUm=7chrMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 3 Mar 2023 at 09:32, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Hmm, I think it would be easier to just have a separate table for
> pg_size_bytes(), rather than reusing pg_size_pretty()'s table. I.e.,
> size_bytes_units[], which would only need name and multiplier columns
> (not round and limit). Done that way, it would be easier to add other
> units later (e.g., non-base-2 units).

Maybe that's worthwhile if we were actually thinking of adding any
non-base 2 units in the future, but if we're not, perhaps it's better
just to have the smaller alias array which for Peter's needs will just
require 1 element + the NULL one instead of 6 + NULL.

In any case, I'm not really sure I see what the path forward would be
to add something like base-10 units would be for pg_size_bytes(). If
we were to change MB to mean 10^6 rather than 2^20 I think many people
would get upset.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-03-03 11:30:59 Re: Fix comments in gistxlogDelete, xl_heap_freeze_page and xl_btree_delete
Previous Message Michael Paquier 2023-03-03 11:13:32 Re: Simplify standby state machine a bit in WaitForWALToBecomeAvailable()