At Thu, 26 May 2022 14:16:37 +0900, Shinya Kato <shinya11.k...@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 > > <nathandboss...@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
