pg_size_pretty, SHOW, and spaces - Mailing list pgsql-hackers

From Christoph Berg
Subject pg_size_pretty, SHOW, and spaces
Date
Msg-id 20160801113552.ntkqnz77l6yvwpjx@msg.df7cb.de
Whole thread Raw
In response to Re: [BUGS] BUG #14244: wrong suffix for pg_size_pretty()  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_size_pretty, SHOW, and spaces  (Bruce Momjian <bruce@momjian.us>)
Re: pg_size_pretty, SHOW, and spaces  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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
unitthat 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



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Oddity in EXPLAIN for foreign/custom join pushdown plans
Next
From: Etsuro Fujita
Date:
Subject: Re: Oddity in EXPLAIN for foreign/custom join pushdown plans