Re: PQinitSSL broken in some use casesf

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PQinitSSL broken in some use casesf
Дата
Msg-id 24147.1238348312@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PQinitSSL broken in some use casesf  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: PQinitSSL broken in some use casesf
Re: PQinitSSL broken in some use casesf
Re: PQinitSSL broken in some use casesf
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Andrew Chernow wrote:
>> 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.

> 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.

You're missing the point, which is that it isn't certain whether the
right thing happens at runtime.  It would be very hard to debug the
failure if an app compiled against new headers was run with an old
shlib.  The separate two-argument function would avoid that: the failure
would manifest as "called function doesn't exist", which would at least
make it obvious what was wrong.

I personally would be happy with the two-argument function solution.
Now, that only addresses the specific problem of libcrypto vs libssl.
IIUC, Merlin's current thought is that we should be looking for a more
general solution.  But it seems a bit dangerous to try to design a
general solution when we have only one example to work from.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: psql \d* and system objects
Следующее
От: Andrew Chernow
Дата:
Сообщение: Re: PQinitSSL broken in some use casesf