Tom Lane wrote: > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
