RE: Allow escape in application_name

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

From: "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
To: 'Fujii Masao' <masao.fujii@oss.nttdata.com>, 'Kyotaro Horiguchi' <horikyota.ntt@gmail.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, "ikedamsh@oss.nttdata.com" <ikedamsh@oss.nttdata.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Date: 2021-10-07T02:46:36Z
Lists: pgsql-hackers
Dear Fujii-san,

Thank you for reviewing!

> +		else if (*p == '-' ? isdigit(p[1]) : isdigit(p[0]))
> +		{
> +			char *endptr;
> +			padding = strtol(p, &endptr, 10);
> 
> Maybe isdigit() and strtol() work differently depending on locale setting?
> If so, I'm afraid that the behavior of this new code would be different from
> process_log_prefix_padding().

(Maybe strtol() should be strtoint(). This is my fault... but anyway)
You afraid that these functions may return non-zero value if locale is not "C"
and inputs are non-ascii characters?
I read the POSIX specification(isdigit: [1], strtol: [2]) and I found that
it suggests such functions are affected by locale settings.

For isdigit():
> The isdigit() and isdigit_l() functions shall test whether c is a character of class digit in the current locale, 
> or in the locale represented by locale, respectively; see XBD Locale.

For strtol()
> In other than the C or POSIX locale, additional locale-specific subject sequence forms may be accepted.

I seeked other sources, but I thought that they did not consider about
locale settings. For example, functions in numutils.c are use such functions
without any locale consideration.

And I considered executing setlocale(LC_CTYPE, "C"), but I found
the following comment pg_locale.c and I did not want to violate the policy.

> * Here is how the locale stuff is handled: LC_COLLATE and LC_CTYPE
> * are fixed at CREATE DATABASE time, stored in pg_database, and cannot
> * be changed. Thus, the effects of strcoll(), strxfrm(), isupper(),
> * toupper(), etc. are always in the same fixed locale.

But isdigit() and strtol() cannot accept multi byte character,
so I also thought we don't have to consider
that some unexpected character is set in LC_CTYPE digit category.

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?

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/isdigit.html
[2]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html

Best Regards,
Hayato Kuroda
FUJITSU LIMITED




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.