On 2021/09/16 12:36, kuroda.hayato@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