Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty() - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
Date
Msg-id CAM-w4HNRZmna6BFRQYDmXV_nH26YAJD-5m2yLHQWrRh08yb9hg@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty()  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
List pgsql-hackers
On Sat, Jul 30, 2016 at 2:47 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> After bouncing on this for a bit I'm inclined to mark the bug itself "won't
> fix" but introduce a "to_binary_iso" function (I'm hopeful a better name
> will emerge...) that will output a number using ISO binary suffixes.  I
> would document this under 9.8 "data type formatting functions" instead of
> within system functions.

I think Bruce's summary is a bit revisionist. All these standards are
attempts to reconcile two different conflicting traditions that have
been conflicting for decades. There's a conflict for a reason though
and the tradition of using powers of 2 is well-ingrained in plenty of
practices and software, not just Postgres.

Personally I'm pretty satisfied with the current mode of operation
because I think powers of 2 are vastly more useful and more likely to
be what the user actually wants. You would be hard pressed to find any
users actually typing KiB or MiB in config files and being surprised
they don't work or any users typing work_mem=100MB and being surprised
that they're not getting 95.367 MiB.

If you really want to support a strict interpretation of the SI
standards then I don't see anything wrong with having a GUC. It
doesn't change the semantics of SQL parsing so the worst-case downside
is that if you change the setting and then reload a config file or if
you move a setting from one place in a config file to another the
interpretation of the config file would change. The best practice
would probably be to set this config at the top of the config file and
nowhere else.


I would suggest having a GUC like "strict_si_units" with false as the
default. If it's true then units like KiB and KB are both accepted and
mean different things. If it's false then still accept both but treat
them as synonyms meaning powers of 2. This means users who don't care
can continue using convenient powers of 2 everywhere without thinking
about it and users who do can start using the new-fangled SI units
(and have the pitfall of accidentally specifying in units of powers of
10).

For outputs like pg_size_pretty, SHOW, and pg_settings you could
either say to always use KiB so that the outputs are always correct to
use regardless of the setting of strict_si_units or you could have it
print KB et al when strict_si_units is false -- the latter have the
advantage that outputs could be copied to older versions safely but
the disadvantage that if you change the setting then the
interpretation of existing config files change. I think it would be
better to print KiB/MiB etc always. I suppose there's the alternative
of trying to guess which unit results in the most concise display but
that seems unnecessarily baroque and likely to just hide mistakes
rather than help.

-- 
greg



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: old_snapshot_threshold allows heap:toast disagreement
Next
From: Tomas Vondra
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)