Re: Allow escape in application_name

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: masao.fujii@oss.nttdata.com
Cc: kuroda.hayato@fujitsu.com, houzj.fnst@fujitsu.com, ikedamsh@oss.nttdata.com, pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
Date: 2021-10-12T06:06:11Z
Lists: 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



Commits

  1. postgres_fdw: Add regression test for postgres_fdw.application_name GUC.

  2. postgres_fdw: Allow postgres_fdw.application_name to include escape sequences.

  3. doc: Add note about postgres_fdw.application_name.

  4. postgres_fdw: Revert unstable tests for postgres_fdw.application_name.

  5. postgres_fdw: Allow application_name of remote connection to be set via GUC.