RE: Allow escape in application_name

Поиск
Список
Период
Сортировка
От kuroda.hayato@fujitsu.com
Тема RE: Allow escape in application_name
Дата
Msg-id TYAPR01MB5866B6E1BB186DF0DF37EFC0F5B19@TYAPR01MB5866.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Allow escape in application_name  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: Allow escape in application_name  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Bandy
Дата:
Сообщение: Re: Lost logs with csvlog redirected to stderr under WIN32 service
Следующее
От: Amit Langote
Дата:
Сообщение: Re: a comment in joinrel.c: compute_partition_bounds()