Re: PQinitSSL broken in some use casesf

On Sat, Mar 28, 2009 at 3:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Well, we are not the "Make Merlin Happy club".  ;-)
>
> Merlin and Andrew were the ones complaining initially.  If they feel
> that a proposed patch doesn't fix the problem, then I'd say that it
> isn't fixing the problem.

+1.

>> My personal opinion is that adding #defines to PQinitSSL() is the right
>> level of fix, and if we ever implement a libpq init mechanism we can
>> convert PGinitSSL to a macro. I am attaching a sample patch for
>> feedback.
>
> This is just a rehash of one of the patches that was discussed earlier.
> There wasn't consensus for it then, and there's not now.

OK, I read this patch. Wazzamatterwithit?

AIUI, we need to define an API that allows libssl and libcrypto to be
initialized or not initialized in any combination. We can do this by
modifying the meaning of the argument to PQinitSSL(), by adding a new
API function, by creating some more general initialization function,
or by some other method. It doesn't REALLY matter. I think I'm
personally of the opinion that PQinitSSL(int) should be left alone and
we should define PQinitSSLCrypto(int, int), just to avoid the
possibility of difficult-to-debug backward-compatibility problems, but
the number of people calling PQinitSSL(2) in existing applications is
doubtless vanishingly small, because there is probably no reason to
call it with a non-constant argument, so who is going to pick 2 rather
than 1? So if someone has some sort of principled objection to adding
a new API call, then let's just modify the behavior of the existing
call instead and move on.

Is there more substance here than meets the eye?

...Robert