Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-03-29 18:56:28
Subject: Re: PQinitSSL broken in some use casesf
Previous:From: Tom LaneDate: 2009-03-29 17:32:32
Subject: Re: psql \d* and system objects

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group