Re: Problems with linking against PostgreSQL 8.4 - Mailing list pgsql-odbc

From Pavel Raiskup
Subject Re: Problems with linking against PostgreSQL 8.4
Date
Msg-id 2385162.nZqbQvSuGZ@nb.usersys.redhat.com
Whole thread Raw
In response to Re: Problems with linking against PostgreSQL 8.4  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-odbc
> > 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.

Ok, we could theoretically remove the "static" call to
PQconnectdbParams() and just have some function pointer which would be set by
lt_dlsym().  But I'm not sure this is fundamentally correct approach.  The
libpq.so library is not IMO designed for such usecase.  From my point of view
is better approach to not link against PQconnectdbParams at all if that
function is not present in the library you are linking against.  So
possible heads-up patch is attached.

> But even more funnily, the only caller of PQconnectdbParams() is
> actually dead code (connection.c):
> [...]
> So we don't actually ever use PQconnectdbParams() for anything.
>
> Want to take a stab at cleaning up that mess?

Actually - there is a lot of non-linux stuff which I am afraid I am unable to
test properly (it would take a lot of time).  Looking at the code, I could
remove a LOT of unused code which would be pity imo.  That code seems to call
for fix rather than removal..  I could be able to help you more;  but I don't
know now what is the safe way..

Pavel

Attachment

pgsql-odbc by date:

Previous
From: "Inoue, Hiroshi"
Date:
Subject: Re: use inet_pton() instead of inet_addr() for ipv4/6
Next
From: Heikki Linnakangas
Date:
Subject: Time for a new release?