Re: PQinitSSL broken in some use casesf

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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.

I think this is where we got stuck because extending libpq with a new
function is a larger API change, and not having a clear plan of what
initialization stuff we might need in the future, it seems unwise, and
also perhaps overkill.

FYI, libcrypto is initialized only in threaded libpq builds, and
non-zero calls to PQinitSSL were always no-ops because they just enabled
the default behavior.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +