Re: libpq API incompatibility between 7.4 and 8.0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: libpq API incompatibility between 7.4 and 8.0
Date
Msg-id 16183.1107542927@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq API incompatibility between 7.4 and 8.0  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: libpq API incompatibility between 7.4 and 8.0  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
>> I suggested to just get_progname() to libpq, not all of path.c.  The
>> odds someone will depend on get_progname() in 8.0 are much less than the
>> problems we will have as listed above.

> Perhaps a question is in order: Are we sure that get_progname() is the only 
> problem, or just the first one the linker found?  Does anyone remember?

The report only showed that that one was the first the linker found.

The 7.4 libpq does include path.c in its entirety, meaning that there
are potentially dependencies out there for all of the symbols defined by
7.4 path.c: is_absolute_path, first_path_separator, last_path_separator,
in addition to get_progname.  In the 8.0 version of path.c these symbols
are intertwined with a bunch more; what's more, is_absolute_path is now
a macro not a routine, so we lost ABI compatibility anyway.  (I do in
fact see is_absolute_path used in 7.4 psql; didn't bother looking for
the others.)

In short, fixing this the way Bruce wants to will be a nontrivial amount
of effort.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: libpq API incompatibility between 7.4 and 8.0
Next
From: Tom Lane
Date:
Subject: Fixing flat user/group files at database startup