BUG #14244: wrong suffix for pg_size_pretty()

On Tue, Jul 12, 2016 at 01:36:38PM +0000, thomas.berger@1und1.de wrote:

The following bug has been logged on the website:

Bug reference: 14244
Logged by: Thomas Berger
Email address: thomas.berger@1und1.de
PostgreSQL version: 9.5.3
Operating system: any
Description:

pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the returned
value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and
should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte

=# select pg_size_pretty(1024000::bigint);
pg_size_pretty
----------------
1000 kB

(Thread moved to hackers.)

The Postgres docs specify that kB is based on 1024 or 2^10:

https://www.postgresql.org/docs/9.6/static/functions-admin.html

Note: The units kB, MB, GB and TB used by the functions
pg_size_pretty and pg_size_bytes are defined using powers of 2 rather
than powers of 10, so 1kB is 1024 bytes, 1MB is 10242 = 1048576 bytes,
and so on.

These prefixes were introduced to GUC variable specification in 2006:

commit b517e653489f733893d61e7a84c118325394471c
Author: Peter Eisentraut <peter_e@gmx.net>
Date: Thu Jul 27 08:30:41 2006 +0000

Allow units to be specified with configuration settings.

and added to postgresql.conf:

# Memory units: kB = kilobytes Time units: ms = milliseconds
# MB = megabytes s = seconds
# GB = gigabytes min = minutes
# TB = terabytes h = hours
# d = days

and the units were copied when pg_size_pretty() was implemented. These
units are based on the International System of Units (SI)/metric.
However, the SI system is power-of-10-based, and we just re-purposed
them to be 1024 or 2^10-based.

However, that is not the end of the story. Things have moved forward
since 2006 and there is now firm support for either KB or KiB to be
1024-based units. This blog post explains the current state of prefix
specification:

http://pchelp.ricmedia.com/kilobytes-megabytes-gigabytes-terabytes-explained/

and here is a summary for 1000/1024-based units:

Kilobyte (Binary, JEDEC) KB 1024
Kilobyte (Decimal, Metric) kB 1000
Kibibyte (Binary, IEC) KiB 1024

You will notice that none of these list kB as 1024, which explains this
bug report.

Yes, we have redefined kB, and documented its use in postgresql.conf and
pg_size_pretty(), but it does not match any recognized standard.

I am thinking Postgres 10 would be a good time to switch to KB as a
1024-based prefix. Unfortunately, there is no similar fix for MB, GB,
etc. 'm' is 'milli' so there we never used mB, so in JEDEC and Metric,
MB is ambiguous as 1000-based or 1024-based.

IEC does give us a unique specification for 'mega', MiB, and GiB, which
might be what we want to use, but that might be too big a change, and I
rarely see those.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Jul 29, 2016 at 08:18:38PM -0400, Bruce Momjian wrote:

However, that is not the end of the story. Things have moved forward
since 2006 and there is now firm support for either KB or KiB to be
1024-based units. This blog post explains the current state of prefix
specification:

http://pchelp.ricmedia.com/kilobytes-megabytes-gigabytes-terabytes-explained/

and here is a summary for 1000/1024-based units:

Kilobyte (Binary, JEDEC) KB 1024
Kilobyte (Decimal, Metric) kB 1000
Kibibyte (Binary, IEC) KiB 1024

Oh, also, here is a Wikipedia article that has a nice chart on the top
right:

https://en.wikipedia.org/wiki/Binary_prefix

and a post that explains some of the background:

http://superuser.com/questions/938234/size-of-files-in-windows-os-its-kb-or-kb

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Tue, Jul 12, 2016 at 01:36:38PM +0000, thomas.berger@1und1.de wrote:

The following bug has been logged on the website:

Bug reference: 14244
Logged by: Thomas Berger
Email address: thomas.berger@1und1.de
PostgreSQL version: 9.5.3
Operating system: any
Description:

pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the

returned

value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and
should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte

=# select pg_size_pretty(1024000::bigint);
pg_size_pretty
----------------
1000 kB

(Thread moved to hackers.)

Yes, we have redefined kB, and documented its use in postgresql.conf and
pg_size_pretty(), but it does not match any recognized standard.

​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.

pg_size_pretty output can continue with a defined role to be used as input
into a GUC variable; and to keep backward compatibility. Add a note near
its definition to use "to_binary_iso" for a standard-conforming output
string.

​David J.

2016-07-30 3:47 GMT+02:00 David G. Johnston <david.g.johnston@gmail.com>:

On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <bruce@momjian.us> wrote:

On Tue, Jul 12, 2016 at 01:36:38PM +0000, thomas.berger@1und1.de wrote:

The following bug has been logged on the website:

Bug reference: 14244
Logged by: Thomas Berger
Email address: thomas.berger@1und1.de
PostgreSQL version: 9.5.3
Operating system: any
Description:

pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the

returned

value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and
should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte

=# select pg_size_pretty(1024000::bigint);
pg_size_pretty
----------------
1000 kB

(Thread moved to hackers.)

Yes, we have redefined kB, and documented its use in postgresql.conf and
pg_size_pretty(), but it does not match any recognized standard.

​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.

pg_size_pretty output can continue with a defined role to be used as input
into a GUC variable; and to keep backward compatibility. Add a note near
its definition to use "to_binary_iso" for a standard-conforming output
string.

We talked about this issue, when I wrote function pg_size_bytes. It is hard
to fix these functions after years of usage. The new set of functions can
be better

pg_iso_size_pretty();
pg_iso_size_bytes();

or shorter name

pg_isize_pretty();
pg_isize_bytes();

Regards

Pavel

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Greg Stark <stark@mit.edu> writes:

I think Bruce's summary is a bit revisionist.

I would say it's a tempest in a teapot.

What I think we should do is accept "kb" and the rest case-insensitively,
print them all in all-upper-case always, and tell standards pedants
to get lost. The idea of introducing either a GUC or new function names
is just silly; it will cause far more confusion and user code breakage
than will result from just leaving well enough alone.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Jul 30, 2016 at 10:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Greg Stark <stark@mit.edu> writes:

I think Bruce's summary is a bit revisionist.

I would say it's a tempest in a teapot.

What I think we should do is accept "kb" and the rest case-insensitively,
print them all in all-upper-case always, and tell standards pedants
to get lost. The idea of introducing either a GUC or new function names
is just silly; it will cause far more confusion and user code breakage
than will result from just leaving well enough alone.

​I wouldn't mind fixing case sensitivity in the process...but I don't think
we need to touch the GUC infrastructure at all.

For a product that has a reasonably high regard for the SQL standard I'd
like to at least keep an open mind about other relevant standards - and if
accommodation is as simple as writing a new function I'd see no reason to
reject such a patch.​ pg_size_pretty never did seem like a good name for a
function with its behavior...lets be open to accepting an improved version
without a pg_ prefix.

We could even avoid a whole new function and add an "iB" template pattern
to the to_char function - although I'm not sure that wouldn't be more
confusing than helpful in practice.

David J.

On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote:

Greg Stark <stark@mit.edu> writes:

I think Bruce's summary is a bit revisionist.

I would say it's a tempest in a teapot.

What I think we should do is accept "kb" and the rest case-insensitively,
print them all in all-upper-case always, and tell standards pedants
to get lost. The idea of introducing either a GUC or new function names
is just silly; it will cause far more confusion and user code breakage
than will result from just leaving well enough alone.

I agree that a GUC and new functions are overkill --- we should just
decide on the format we want to output and what to support for input.

As logical as the IEC format appears, I just don't think the Ki/Mi/Gi
prefixes are used widely enough for us to use it --- I think it will
cause too many problem reports:

https://en.wikipedia.org/wiki/Binary_prefix

I have developed two possible patches for PG 10 --- the first one merely
allows "KB" to be used in addition to the existing "kB", and documents
this as an option.

The second patch does what Tom suggests above by outputting only "KB",
and it supports "kB" for backward compatibility. What it doesn't do is
to allow arbitrary case, which I think would be a step backward. The
second patch actually does match the JEDEC standard, except for allowing
"kB".

I also just applied a doc patch that increases case and spacing
consistency in the use of kB/MB/GB/TB.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

On 07/30/2016 11:16 AM, Bruce Momjian wrote:

On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote:

Greg Stark <stark@mit.edu> writes:

I agree that a GUC and new functions are overkill --- we should just
decide on the format we want to output and what to support for input.

As logical as the IEC format appears, I just don't think the Ki/Mi/Gi
prefixes are used widely enough for us to use it --- I think it will
cause too many problem reports:

https://en.wikipedia.org/wiki/Binary_prefix

I have developed two possible patches for PG 10 --- the first one merely
allows "KB" to be used in addition to the existing "kB", and documents
this as an option.

The second patch does what Tom suggests above by outputting only "KB",
and it supports "kB" for backward compatibility. What it doesn't do is
to allow arbitrary case, which I think would be a step backward. The
second patch actually does match the JEDEC standard, except for allowing
"kB".

I also just applied a doc patch that increases case and spacing
consistency in the use of kB/MB/GB/TB.

+1

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Bruce Momjian 2016-07-30 <20160730181643.GD22405@momjian.us>

I also just applied a doc patch that increases case and spacing
consistency in the use of kB/MB/GB/TB.

Hi,

PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:

# select pg_size_pretty((2^20)::bigint);
pg_size_pretty
────────────────
1024 kB

SHOW does not:

# show work_mem;
work_mem
──────────
1MB

The SHOW output is formatted by _ShowOption() using 'INT64_FORMAT "%s"',
via convert_from_base_unit(). The latter has a comment attached...
/*
* Convert a value in some base unit to a human-friendly unit. The output
* unit is chosen so that it's the greatest unit that can represent the value
* without loss. For example, if the base unit is GUC_UNIT_KB, 1024 is
* converted to 1 MB, but 1025 is represented as 1025 kB.
*/
... where the spaces are present again.

General typesetting standard seems to be "1 MB", i.e. to include a
space between value and unit. (This would also be my preference.)

Opinions? (I'd opt to insert spaces in the docs now, and then see if
inserting a space in the SHOW output is acceptable for 10.0.)

Christoph

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Aug 1, 2016 at 01:35:53PM +0200, Christoph Berg wrote:

Re: Bruce Momjian 2016-07-30 <20160730181643.GD22405@momjian.us>

I also just applied a doc patch that increases case and spacing
consistency in the use of kB/MB/GB/TB.

Hi,

PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:

# select pg_size_pretty((2^20)::bigint);
pg_size_pretty
────────────────
1024 kB

SHOW does not:

# show work_mem;
work_mem
──────────
1MB

Yes, that is inconsistent. I have updated my attached patch to remove
spaces between the number and the units --- see below.

The SHOW output is formatted by _ShowOption() using 'INT64_FORMAT "%s"',
via convert_from_base_unit(). The latter has a comment attached...
/*
* Convert a value in some base unit to a human-friendly unit. The output
* unit is chosen so that it's the greatest unit that can represent the value
* without loss. For example, if the base unit is GUC_UNIT_KB, 1024 is
* converted to 1 MB, but 1025 is represented as 1025 kB.
*/
... where the spaces are present again.

General typesetting standard seems to be "1 MB", i.e. to include a
space between value and unit. (This would also be my preference.)

Opinions? (I'd opt to insert spaces in the docs now, and then see if
inserting a space in the SHOW output is acceptable for 10.0.)

I went through the docs a few days ago and committed a change to removed
spaces between the number and units in the few cases that had them ---
the majority didn't have spaces.

Looking at the Wikipedia article I posted earlier, that also doesn't use
spaces:

https://en.wikipedia.org/wiki/Binary_prefix

I think the only argument _for_ spaces is the output of pg_size_pretty()
now looks odd, e.g.:

10 | 10 bytes | -10 bytes
1000 | 1000 bytes | -1000 bytes
1000000 | 977KB | -977KB
1000000000 | 954MB | -954MB
1000000000000 | 931GB | -931GB
1000000000000000 | 909TB | -909TB
^^^^^ ^^^^^

The issue is that we output "10 bytes", not "10bytes", but for units we
use "977KB". That seems inconsistent, but it is the normal policy
people use. I think this is because "977KB" is really "977K bytes", but
we just append the "B" after the "K" for bevity.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

On 7/30/16 2:16 PM, Bruce Momjian wrote:

The second patch does what Tom suggests above by outputting only "KB",
and it supports "kB" for backward compatibility. What it doesn't do is
to allow arbitrary case, which I think would be a step backward. The
second patch actually does match the JEDEC standard, except for allowing
"kB".

If we're going to make changes, why not bite the bullet and output KiB?

I have never heard of JEDEC, so I'm less inclined to accept their
"standard" at this point.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 7/30/16 1:18 AM, Pavel Stehule wrote:

We talked about this issue, when I wrote function pg_size_bytes. It is
hard to fix these functions after years of usage. The new set of
functions can be better

pg_iso_size_pretty();
pg_iso_size_bytes();

One thing that would actually be nice for other reasons as well is a
version of pg_size_pretty() that lets you specify the output unit, say,
as a second argument. Because sometimes you want to compare two tables
or something, and tells you one is 3GB and the other is 783MB, which
doesn't really help. If I tell it to use 'MB' as the output unit, I
could get comparable output.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Aug 1, 2016 at 02:48:55PM -0400, Peter Eisentraut wrote:

On 7/30/16 2:16 PM, Bruce Momjian wrote:

The second patch does what Tom suggests above by outputting only "KB",
and it supports "kB" for backward compatibility. What it doesn't do is
to allow arbitrary case, which I think would be a step backward. The
second patch actually does match the JEDEC standard, except for allowing
"kB".

If we're going to make changes, why not bite the bullet and output KiB?

I have never heard of JEDEC, so I'm less inclined to accept their
"standard" at this point.

I already address this. While I have never heard of JEDEC either, I
have seen KB, and have never seen KiB, hence my argument that KiB would
lead to more confusion than we have now.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8/1/16 7:35 AM, Christoph Berg wrote:

PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:

# select pg_size_pretty((2^20)::bigint);
pg_size_pretty
────────────────
1024 kB

because it's "pretty" :)

SHOW does not:

# show work_mem;
work_mem
──────────
1MB

The original idea might have been to allow that value to be passed back
into the settings system, without having to quote the space. I'm not
sure, but I think changing that might cause some annoyance.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2016-08-01 20:51 GMT+02:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:

On 7/30/16 1:18 AM, Pavel Stehule wrote:

We talked about this issue, when I wrote function pg_size_bytes. It is
hard to fix these functions after years of usage. The new set of
functions can be better

pg_iso_size_pretty();
pg_iso_size_bytes();

One thing that would actually be nice for other reasons as well is a
version of pg_size_pretty() that lets you specify the output unit, say,
as a second argument. Because sometimes you want to compare two tables
or something, and tells you one is 3GB and the other is 783MB, which
doesn't really help. If I tell it to use 'MB' as the output unit, I
could get comparable output.

It is looks like some convert function

pg_size_to(size, unit, [others ... rounding, truncating]) returns numeric

select pg_size_to(1024*1024, 'KB')

Regards

Pavel

Re: Peter Eisentraut 2016-08-01 <f3e021d3-d843-04a5-d816-6921309b3bf1@2ndquadrant.com>

PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:

# select pg_size_pretty((2^20)::bigint);
pg_size_pretty
────────────────
1024 kB

because it's "pretty" :)

:)

SHOW does not:

# show work_mem;
work_mem
──────────
1MB

The original idea might have been to allow that value to be passed back
into the settings system, without having to quote the space. I'm not
sure, but I think changing that might cause some annoyance.

That's a good argument for keeping it that way, yes.

Re: Bruce Momjian 2016-08-01 <20160801162508.GA28246@momjian.us>

Looking at the Wikipedia article I posted earlier, that also doesn't use
spaces:

https://en.wikipedia.org/wiki/Binary_prefix

That article has plenty of occurrences of "10 MB" "528 MB/s" and the
like.

I think the only argument _for_ spaces is the output of pg_size_pretty()
now looks odd, e.g.:

10 | 10 bytes | -10 bytes
1000 | 1000 bytes | -1000 bytes
1000000 | 977KB | -977KB
1000000000 | 954MB | -954MB
1000000000000 | 931GB | -931GB
1000000000000000 | 909TB | -909TB
^^^^^ ^^^^^

The issue is that we output "10 bytes", not "10bytes", but for units we
use "977KB". That seems inconsistent, but it is the normal policy
people use. I think this is because "977KB" is really "977K bytes", but
we just append the "B" after the "K" for bevity.

It's the other way round:

https://en.wikipedia.org/wiki/International_System_of_Units#General_rules

| The value of a quantity is written as a number followed by a space
| (representing a multiplication sign) and a unit symbol; e.g., 2.21 kg
[...]

I'd opt to omit the space anywhere where the value is supposed to be
fed back into the config (SHOW, --parameters), but use the "pretty"
format with space everywhere otherwise (documentation, memory counts
in explain output, pg_size_pretty() etc.)

Christoph

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 2, 2016 at 11:29:01AM +0200, Christoph Berg wrote:

The issue is that we output "10 bytes", not "10bytes", but for units we
use "977KB". That seems inconsistent, but it is the normal policy
people use. I think this is because "977KB" is really "977K bytes", but
we just append the "B" after the "K" for bevity.

It's the other way round:

https://en.wikipedia.org/wiki/International_System_of_Units#General_rules

| The value of a quantity is written as a number followed by a space
| (representing a multiplication sign) and a unit symbol; e.g., 2.21 kg
[...]

I'd opt to omit the space anywhere where the value is supposed to be
fed back into the config (SHOW, --parameters), but use the "pretty"
format with space everywhere otherwise (documentation, memory counts
in explain output, pg_size_pretty() etc.)

Yes, that's a strong argument for using a space. I have adjusted the
patch to use spaces in all reasonable places. Patch attached, which I
have gzipped because it was 133 KB. (Ah, see what I did there?) :-)

I am thinking of leaving the 9.6 docs alone as I have already made them
consistent (no space) with minimal changes. We can make it consistent
the other way in PG 10.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +

On 8/2/16 12:51 PM, Bruce Momjian wrote:

Yes, that's a strong argument for using a space. I have adjusted the
patch to use spaces in all reasonable places. Patch attached, which I
have gzipped because it was 133 KB. (Ah, see what I did there?) :-)

I am thinking of leaving the 9.6 docs alone as I have already made them
consistent (no space) with minimal changes. We can make it consistent
the other way in PG 10.

I don't think anyone wanted to *remove* the spaces in the documentation.
I think this change makes the documentation harder to read.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers