Re: Allow escape in application_name

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-12-24 04:49:15
Message-ID: 20211224.134915.1522953222109930961.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 23 Dec 2021 23:10:38 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>
>
> On 2021/12/17 16:50, Kyotaro Horiguchi wrote:
> > Thus rewriting the code we're focusing on like the following would
> > make sense to me.
> >
> >> if (strcmp(keywords[i], "application_name") == 0)
> >> {
> >> values[i] = process_pgfdw_appname(values[i]);
> >>
> >> /*
> >> * Break if we have a non-empty string. If we end up failing with
> >> * all candidates, fallback_application_name would work.
> >> */
> >> if (appanme[0] != '\0')

(appname?)

> >> break;
> >> }
>
> I'm ok to remove the check "values[i] != NULL", but think that it's
> better to keep the other check "*(values[i]) != '\0'" as it
> is. Because *(values[i]) can be null character and it's a waste of
> cycles to call process_pgfdw_appname() in that case.

Right. I removed too much.

> > Thanks for revisiting.
> >
> >> #1. use "[unknown]"
> >> #2. add the check but not use "[unknown]"
> >> #3. don't add the check (i.e., what the current patch does)
> >>
> >> For now, I'm ok to choose #2 or #3.
> > As I said before, given that we don't show "unkown" or somethig like
> > as the fallback, I'm fine with not having a NULL check since anyway it
> > bumps into SEGV immediately. In short I'm fine with #3 here.
>
> Yep, let's use #3 approach.

Agreed.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-12-24 05:34:34 Re: row filtering for logical replication
Previous Message Kyotaro Horiguchi 2021-12-24 04:42:14 Re: more descriptive message for process termination due to max_slot_wal_keep_size