Re: PQinitSSL broken in some use casesf

Tom Lane wrote:
> 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.

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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +