Re: Allow escape in application_name - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Allow escape in application_name
Date
Msg-id 20211012.150611.237229758911985695.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Allow escape in application_name  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Allow escape in application_name  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
At Tue, 12 Oct 2021 13:25:01 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> 
> 
> On 2021/10/07 11:46, kuroda.hayato@fujitsu.com wrote:
> > So now we can choose from followings:
> >* ignore such differences and use isdigit() and strtol()
> > * give up using them and implement two static support functions
> >How do you think? Someone knows any other knowledge about locale?
> 
> Replacing process_log_prefix_padding() with isdigit()+strtol() is
> just refactoring and doesn't provide any new feature. So they
> basically should work in the same way. If the behavior of
> isdigit()+strtol()
> can be different from process_log_prefix_padding(), I'd prefer to
> the latter option you suggested, i.e., give up using
> isdigit()+strtol().
> 
> OTOH, of course if the behaviors of them are the same,
> I'm ok to use isdigit()+strtol(), though.

Hmm. It look like behaving a bit xdifferently. At least for example,
for "%-X", current code treats it as 0 padding but the patch treats it
as -1.

By the way, the current code is already a kind of buggy.  I think I
showed an example like:

"%4%5%6%7p" is converted to "57p".  Do we need to imitate that bug
with this patch?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Error "initial slot snapshot too large" in create replication slot
Next
From: Bharath Rupireddy
Date:
Subject: Re: Reword docs of feature "Remove temporary files after backend crash"