On 12/07/2013 11:40 AM, Pavel Raiskup wrote:
> On Friday, December 06, 2013 23:11:40 Heikki Linnakangas wrote:
>> On 12/06/2013 08:42 PM, Pavel Raiskup wrote:
>>>>> I see that the symbol was added to PostgreSQL project in ~2010 and it
>>>>> seems to be a problem. Should I expect that newer drivers are able to be
>>>>> run against older (still supported by PostgreSQL community) PostgreSQL
>>>>> server, namely 8.4.13?
>>>>
>>>> You need to compile against a newer libpq but after that,
>>>> you can connect to an older server.
>>>
>>> Ah yes, that would be possible, thanks! But still, if that is expected -
>>> we should at least check older libpq's via configure.ac and blacklist
>>> them, or?
>>
>> Yeah, a configure test would be nice. Patches are welcome ;-)
>
> I'll be glad, just to make it clear :). Do you want remove support for
> libpq 8.4 completely or make configure check for PQconnectdbParams (to
> make the code work without PQconnectdbParams)? The later makes more sense
> to me as 8.4 is still not dead (and will probably exist in REL8_4_STABLE
> branch some time)
Actually, now that I look closer into that, the situation is a bit
messy. There's a runtime check in loadlib.c, which tests if the version
of libpq being used has the PQconnectdbParams() function. But we still
link against libpq normally, so the library still won't load if that
function isn't present, even though we have the code in place to check
and refrain from actually calling it. So that's a bit broken.
But even more funnily, the only caller of PQconnectdbParams() is
actually dead code (connection.c):
> if (FALSE && connect_with_param_available())
> {
> const char *opts[PROTOCOL3_OPTS_MAX], *vals[PROTOCOL3_OPTS_MAX];
>
> protocol3_opts_array(self, opts, vals, TRUE, sizeof(opts) / sizeof(opts[0]));
> pqconn = CALL_PQconnectdbParams(opts, vals, &libpqLoaded);
> }
> else
> {
So we don't actually ever use PQconnectdbParams() for anything.
Want to take a stab at cleaning up that mess?
- Heikki