Re: Allow escape in application_name

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: kuroda(dot)hayato(at)fujitsu(dot)com
Cc: masao(dot)fujii(at)oss(dot)nttdata(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-14 01:09:56
Message-ID: 20211014.100956.1736949970867711013.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 13 Oct 2021 11:05:19 +0000, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> wrote in
> Dear Horiguchi-san, Fujii-san,
>
> Perfect work... Thank you for replying and analyzing!
>
> > A. "^-?[0-9]+.*" : returns valid padding. p goes after the last digit.
> > B. "^[^0-9-].*" : padding = 0, p doesn't advance.
> > C. "^-[^0-9].*" : padding = 0, p advances by 1 byte.
> > D. "^-" : padding = 0, p advances by 1 byte.
> > (if *p == 0 then breaks)
>
> I confirmed them and your patterns are correct.

Thanks for the confirmation.

> > If we wan to make the behaviors C and D same with the current, the
> > else clause should be like the follows, but I don't think we need to
> > do that.
> > else
> > {
> > padding = 0;
> > if (*p == '-')
> > p++;
> > }
>
> This treatments is not complex so I want to add them if possible.

Also I don't oppose to do that.

> > One possible cause of a difference in behavior is character class
> > handling including multibyte characters of isdigit and strtol. If
> > isdigit accepts '一' as a digit (some platforms might do this) , and
> > strtol doesn't (I believe it is universal behavior), '%一0p' is
> > converted to '%' and the pointer moves onto '一'. But I don't think we
> > need to do something for such a crazy specification.
>
> Does isdigit() understand multi-byte character correctly? The arguments
> of isdigit() is just a unsigned char, and this is 1byte.
> Hence I thought that they cannot distinguish 'ー'.
..
> Sorry, but I referred some wrong doc. Please ignore here...

I'm not sure. All of it is a if-story. z/OS's isdigit is defined as
"Test for a decimal digit, as defined in the digit locale source file
and in the digit class of the LC_CTYPE category of the current
locale.", which I read it as "it accepts multibyte strings" but of
course I'm not sure that's correct.

On CentOS8, and for Japanese letters, both iswdigit(L'ー') and
iswdigit(L'0') return false so, assuming the same character
classfication scheme that is implementation dependent, I guess z/OS's
isdigit would behave the same way with CentOS's isdigit.

Hoever, regardless of the precise behavior,

> But, of cause I agreed this is the crazy case.

Yes, I meant that that doesn't matter.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-10-14 01:35:00 Re: Missing log message in recoveryStopsAfter() for RECOVERY_TARGET_TIME recovery target type
Previous Message Masahiko Sawada 2021-10-14 00:59:23 Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES