Re: PQinitSSL broken in some use casesf

On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> Well, you could create PQinitSSLExtended, but, as you say, the use
>>>> case is pretty narrow...
>>>> It would help if there were a PQgetLibraryVersion() function.
>>>
>>> Help how? There is nothing an app can do to work around the problem
>>> AFAICS. Or if there were, we should just document it and not change
>>> the code --- the use case for this is evidently too narrow to justify
>>> complicating libpq's API even more.
>
>> It would let you assert that you were running against a version of
>> libpq that has the functionality that you are attempting to use, thus
>> eliminating the risk of silent failure.
>
> If that's all you want, then PQinitSSLExtended is a perfectly good
> answer. Your app will fail to link if you try to use a library
> version that hasn't got it.
>
> I think documenting the workaround is a sufficient answer though.

I don't think you can get way with that this time. wsa cleanup was a
mainly harmless side effect. This is a nasty 'maybe it works, maybe
it doesn't' virtually impossible to debug problem. We caught it on a
particular platform (windows, iirc) when deep in our code a mutex call
deadlocked when it shouldn't have, after weeks of working ok.
debugging nightmare.

PQinitSSL is *broken*. It's always been broken. Since it already
takes a parameter, I say add a special switch...the backwards
compatibility danger doesn't seem too bad.

merlin