Re: PQinitSSL broken in some use casesf

Andrew Chernow <ac@esilo.com> writes:
>> One problem with this patch is that a libpq app using PQinitSSL(0) is 
>> under the assumption that this shuts off ssl init and crypto init.  That 
>> app might be doing its own crypto init which would be overwritten by 
>> libpq because the app is unaware of PQinitCrypto (if and when it 
>> eventually links with 8.4 libpq).  This feels like a very uncommon 
>> situation, but a possible gotcha.

> I take that back.  Not so sure it is uncommon,

I agree, we should *not* change the existing behavior for either case.
This probably means that an independent PQinitCrypto function is the
wrong thing, even though it would've been the cleanest solution if
we were starting from scratch.

At this point I like Merlin's proposal of a third parameter value to
PQinitSSL the best.

> /* IMHO appending "Ex" is a little nicer */
> void PQinitSSLEx(int ssl_init, int crypto_init);

Ugh, ugh, ugh.  We do not do "Ex" around here --- uninterpretable
abbreviations are not helpful to the reader.  Call it Extended
if you must have it.

Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it?
        regards, tom lane