On 2021/09/16 12:36, kuroda.hay...@fujitsu.com wrote:
you mean that this is not strtoXXX, right?
Yes, the behavior of process_log_prefix_padding() is different from strtoint() or pg_strtoint32(). For example, how the heading space characters are handled is different. If we use the name like pg_fast_strtoint(), we might be likely to replace the existing strtoint() or pg_strtoint32() with pg_fast_strtoint() because its name contains "fast", for better performance. But we should not do that because their behavior is different.
If so we should go back to process_padding().... Horiguchi-san, do you have any idea?
At least for me process_padding() sounds like the function is actually doing the padding operation. This is not what the function does. So how about something like parse_padding(), parse_padding_format()?
And I added pg_restrict keywords for compiler optimizations.
I'm not sure how much it's worth doing this here. If this change is helpful for better performance or something, IMO it's better to propose this separately.
I agreed that (2) and (3) breaks the rule which should override server option. Hence I chose (4), values[i] substituted to buf.data in any case. Attached is the latest version.
Thanks! Will review the patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
