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.
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.
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2009-02-10 17:02:39|
|Subject: Re: [COMMITTERS] pg-migrator - src: Add support for specifying port
|Previous:||From: Bruce Momjian||Date: 2009-02-10 16:54:28|
|Subject: Re: PQinitSSL broken in some use casesf|