From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | masao(dot)fujii(at)oss(dot)nttdata(dot)com |
Cc: | kuroda(dot)hayato(at)fujitsu(dot)com, houzj(dot)fnst(at)fujitsu(dot)com, ikedamsh(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: Allow escape in application_name |
Date: | 2021-10-12 06:06:11 |
Message-ID: | 20211012.150611.237229758911985695.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 12 Oct 2021 13:25:01 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>
>
> On 2021/10/07 11:46, kuroda(dot)hayato(at)fujitsu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-10-12 06:40:39 | Re: Reword docs of feature "Remove temporary files after backend crash" |
Previous Message | Dilip Kumar | 2021-10-12 06:00:43 | Re: Error "initial slot snapshot too large" in create replication slot |