From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Andrew Chernow <ac(at)esilo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PQinitSSL broken in some use casesf |
Date: | 2009-03-29 17:38:32 |
Message-ID: | 24147.1238348312@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Andrew Chernow wrote:
>> 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.
> 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.
You're missing the point, which is that it isn't certain whether the
right thing happens at runtime. It would be very hard to debug the
failure if an app compiled against new headers was run with an old
shlib. The separate two-argument function would avoid that: the failure
would manifest as "called function doesn't exist", which would at least
make it obvious what was wrong.
I personally would be happy with the two-argument function solution.
Now, that only addresses the specific problem of libcrypto vs libssl.
IIUC, Merlin's current thought is that we should be looking for a more
general solution. But it seems a bit dangerous to try to design a
general solution when we have only one example to work from.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-03-29 18:56:28 | Re: PQinitSSL broken in some use casesf |
Previous Message | Tom Lane | 2009-03-29 17:32:32 | Re: psql \d* and system objects |