Restructure formatting.c's NUM_processor() to add some const-sanity. NUM_processor() is an under-documented mess. Depending on the value of is_to_char, it either reads "inout" and writes "number", or the other way around. That makes it impossible to label either string "const", which seems like a minimum expectation in 2026. It also complicates replacing the output buffer with a StringInfo: we'd have to convert both strings, which is pretty pointless for the input side.
Moreover, we're buying very little code savings by doing it like this, since a large majority of the function's code has to be wrapped inside "if (is_to_char)" tests. To fix, split the function into NUM_processor_from_char() and NUM_processor_to_char(), and rename/const-ify arguments as appropriate. Both paths now read from "const char *input" and write to "char *output". This patch doesn't intend to make any algorithmic changes, it's just mechanical code rearrangement and symbol renaming. The only real exception is that I got rid of passing "input_len" to NUM_processor_from_char()'s subroutines in favor of storing "const char *input_end" in NUMProc. Author: Tom Lane <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Discussion: https://postgr.es/m/[email protected] Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/28c5d0724875591ff55dd85a065207badc2fa8ad Modified Files -------------- src/backend/utils/adt/formatting.c | 933 +++++++++++++++++++++---------------- 1 file changed, 521 insertions(+), 412 deletions(-)
