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-12-17 03:06:12
Message-ID: 20211217.120612.272223393619050796.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Fri, 17 Dec 2021 02:42:25 +0000, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> wrote in
> Dear Fujii-san,
>
> Sorry I forgot replying your messages.
>
> > >> if (strcmp(keywords[i], "application_name") == 0 &&
> > >> values[i] != NULL && *(values[i]) != '\0')
> > >
> > > I'm not sure but do we have a case that values[i] becomes NULL
> > > even if keywords[i] is "application_name"?
> >
> > No for now, I guess. But isn't it safer to check that, too? I also could not find strong
> > reason why that check should be dropped. But you'd like to drop that?
>
> No, I agreed the new checking. I'm just afraid of my code missing.

FWIW, I don't understand why we care of the case where the function
itself changes its mind to set values[i] to null while we ignore the
possibility that some module at remote is modified so that some global
variables to be NULL. I don't mind wheter we care for NULLs or not
but I think we should be consistent at least in a single patch.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2021-12-17 03:09:58 Re: WIP: WAL prefetch (another approach)
Previous Message kuroda.hayato@fujitsu.com 2021-12-17 02:42:25 RE: Allow escape in application_name