Re: Allow escape in application_name

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "ikedamsh(at)oss(dot)nttdata(dot)com" <ikedamsh(at)oss(dot)nttdata(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Allow escape in application_name
Date: 2021-09-16 05:44:39
Message-ID: 6d6df7de-344a-041b-0768-c8b90cd3b166@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/09/16 12:36, kuroda(dot)hayato(at)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-09-16 05:54:11 Re: Added schema level support for publication.
Previous Message Pavel Stehule 2021-09-16 05:15:31 Re: Schema variables - new implementation for Postgres 15