From 81839cc4ebf566ea9f3e6d819c7338b98cdec374 Mon Sep 17 00:00:00 2001 From: Peter Rajnoha Date: Mon, 15 Aug 2022 11:40:52 +0200 Subject: report: report numeric values (not string synonyms) for NUM and BIN fields with json_std format Internally, NUM and BIN fields are marked as DM_REPORT_FIELD_TYPE_NUM_NUMBER through libdevmapper API. The new 'json_std' format mandates that the report string representing such a value must be a number, not an arbitrary string. This is because numeric values in 'json_std' format do not have double quotes around them. This practically means, we can't use string synonyms ("named reserved values") for such values and the report string must always represent a proper number. With 'json' and 'basic' formats, this is not an issue because 'basic' format doesn't have any structure or typing at all and 'json' format puts all values in quotes, including numeric ones. --- man/lvmreport.7_main | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'man') diff --git a/man/lvmreport.7_main b/man/lvmreport.7_main index 1ef5d25db..0015cdce7 100644 --- a/man/lvmreport.7_main +++ b/man/lvmreport.7_main @@ -1335,6 +1335,10 @@ compared to the original \fBjson\fP format: .RS - it does not use double quotes around numeric values, .br +- numeric values are always expressed as numbers, not reserved strings + representing them (this also means that report/binary_values_as_numeric=1 + setting is forced) +.br - it uses 'null' for undefined numeric values, .br - it prints string list as proper JSON array of strings instead of a single string. -- cgit v1.2.1