Re: PQinitSSL broken in some use casesf
От | Bruce Momjian |
---|---|
Тема | Re: PQinitSSL broken in some use casesf |
Дата | |
Msg-id | 200903290403.n2T43jG23323@momjian.us обсуждение исходный текст |
Ответ на | Re: PQinitSSL broken in some use casesf (Andrew Chernow <ac@esilo.com>) |
Ответы |
Re: PQinitSSL broken in some use casesf
|
Список | pgsql-hackers |
Andrew Chernow wrote: > Robert Haas wrote: > > > > Is there more substance here than meets the eye? > > > > No, you about summed it up. We need a way to init libssl and libcrypto > in any combo. Along the way, PQinit() was discussed which may have > muddied the waters. > > I prefer leaving the PQinitSSL function alone, thus my patch that > implements PQinitSecure(flags). > > Adding PQinitSSL(new_value) seem reasonable to me. My only complaint > has been that the API user has no way of knowing if the function > understood their request. An older libpq would treat any non-zero > argument as one, which would silently fail/mis-behave from a new apps > perspective. Not sure this can be solved. > > In the end, anyway you do it will have an issue or two. I agree that it > really doesn't matter, all methods would probably do the trick. I think doing PQinitSSL(new_value) is probably the least invasive change to solve this, which is why I suggested it. It does have a compile-time check by referencing the #define. We never documented the valid values to PQinitSSL(), and no one ever reported this as a bug, so the existing use of PQinitSSL() is probably very small. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: