At Thu, 26 May 2022 14:16:37 +0900, Shinya Kato <Shinya11.Kato@oss.nttdata.com> wrote in
> On 2022-05-25 12:47, Michael Paquier wrote:
> > On Wed, May 25, 2022 at 11:07:52AM +0900, Kyotaro Horiguchi wrote:
> >> I reproduced the same failure at my hand and identified the
> >> cause. Windows' version of getopt_long seems to dislike that
> >> non-optional parameters precedes options.
> > Tweaking the list of arguments in some commands kicked by the TAP
> > tests to satisfy our implementation of getopt_long() has been the
> > origin of a couple of portability fixes, like ffd3980.
>
> Thanks! I fixed it.
>
>
> On 2022-05-25 11:07, Kyotaro Horiguchi wrote:
> > At Tue, 24 May 2022 10:09:10 -0700, Nathan Bossart
> > <nathandbossart@gmail.com> wrote in
> >> We're still missing some "fancier" string patterns in the tests, but
> >> we
> >> might just be nitpicking at this point.
> > Such "fancier" strings should be properly handled by FmtId() and
> > appendStringLiteralConn. If this is a privilege escalating command,
> > we should have ones but this is not.
>
> Sorry, I didn't quite understand the "fancier" pattern. Is a string
> like this patch correct?
FWIW, the "fancy" here causes me to think about something likely to
cause syntax breakage of the query to be sent.
createuser -a 'user"1' -a 'user"2' 'user"3'
createuser -v "2023-1-1'; DROP TABLE public.x; select '" hoge
BUT, thses should be prevented by the functions enumerated above. So,
I don't think we need them.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center