Andrew Chernow wrote:
> Robert Haas wrote:
> > Is there more substance here than meets the eye?
> No, you about summed it up. We need a way to init libssl and libcrypto
> in any combo. Along the way, PQinit() was discussed which may have
> muddied the waters.
> I prefer leaving the PQinitSSL function alone, thus my patch that
> implements PQinitSecure(flags).
> 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. An older libpq would treat any non-zero
> argument as one, which would silently fail/mis-behave from a new apps
> perspective. Not sure this can be solved.
> In the end, anyway you do it will have an issue or two. I agree that it
> really doesn't matter, all methods would probably do the trick.
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.
We never documented the valid values to PQinitSSL(), and no one ever
reported this as a bug, so the existing use of PQinitSSL() is probably
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ If your life is a hard drive, Christ can be your backup. +
In response to
pgsql-hackers by date
|Next:||From: Guillaume Smet||Date: 2009-03-29 09:52:01|
|Subject: Re: 8.4 release notes proof reading 1/2|
|Previous:||From: Andrew Chernow||Date: 2009-03-29 03:24:56|
|Subject: Re: PQinitSSL broken in some use casesf|