Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> 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.
Advertising
*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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
