Re: PQinitSSL broken in some use casesf

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

In response to

Responses

Browse pgsql-hackers by date

  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