Re: Naming of gss_accept_deleg
От | Abhijit Menon-Sen |
---|---|
Тема | Re: Naming of gss_accept_deleg |
Дата | |
Msg-id | ZGuERm/B2UCuajzz@toroid.org обсуждение исходный текст |
Ответ на | Re: Naming of gss_accept_deleg (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Naming of gss_accept_deleg
Re: Naming of gss_accept_deleg |
Список | pgsql-hackers |
At 2023-05-22 09:42:44 -0400, tgl@sss.pgh.pa.us wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > I noticed that the value that enables this feature at libpq client side > > is 'enable'. However, for other Boolean settings like sslsni, > > keepalives, requiressl, sslcompression, the value that enables feature > > is '1' -- we use strings only for "enum" type of settings. > > > Also, it looks like connectOptions2() doesn't validate the string value. > > Hmm, it certainly seems like this ought to accept exactly the > same inputs as other libpq boolean settings. I can take a look > unless somebody else is already on it. Here's the diff, but the 0/1 values of settings like sslsni and sslcompression don't seem to be validated anywhere, unlike the string options in connectOptions2, so I didn't do anything for gssdelegation. (I've never run the Kerberos tests before, but I changed one "gssdelegation=disable" to "gssdelegation=1" and got a test failure, so they're probably working as expected.) -- Abhijit
Вложения
В списке pgsql-hackers по дате отправления: