Tom Lane wrote:
> Dave Page <dpage@postgresql.org> writes:
>> Tom Lane wrote:
>>> Doesn't really matter. Even if we were willing to hack our own client
>>> apps like that (which I'm not), we can *not* transfer such a requirement
>>> onto every libpq-using application. It's just not acceptable.
>
>> *We're* not transfering any requirement. I've fixed pgAdmin for example
>> without any need to touch any Postgres code.
>
> Well, yeah, we are, as evidenced by the fact that you had to do
> something to pgAdmin. Every other application that uses libpq would
> also be facing source code changes to make it work.
Yes, but it's not us requiring it (except in as much as we provide some
level of SSL support) but the OpenSSL crew.
> Is there really no way to solve this within libpq?
Including the applink code in libpq was the first think I tried but it
doesn't work (apparently because there is no way to ensure that any
random module containing it isn't unloaded before it's needed which
sorta makes sense).
I did stumble across this text on a mailing list in response to someone
with a similar problem in some JNI code. I know little of the OpenSSL
API, but perhaps it rings bells with you before I spend my evening
trying to figure it out?
-----
But for new and evolving code [I suppose JNI would be rather
new and evolving] applink should not be preferable option, as there is a
way around it, namely avoid passing FILE* to BIO, but instead let BIO
open files for you, i.e. avoid BIO_new_fp and stick to BIO_new_filename.
Note that applink is engaged purely on demand and it doesn't have to be
present in application if application doesn't pass FILE* to BIO.
-----
/D
