Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

• Re: libpq API incompatibility between 7.4 and 8.0 at 2005-02-04 18:35:23 from Peter Eisentraut

Responses

• Re: libpq API incompatibility between 7.4 and 8.0 at 2005-02-04 21:33:39 from Bruce Momjian

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2005-02-04 20:16:33
	Subject: Fixing flat user/group files at database startup
Previous:	From: Peter Eisentraut	Date: 2005-02-04 18:35:23
	Subject: Re: libpq API incompatibility between 7.4 and 8.0

pgsql-patches by date

Next:	From: Bruce Momjian	Date: 2005-02-04 21:33:39
	Subject: Re: libpq API incompatibility between 7.4 and 8.0
Previous:	From: Peter Eisentraut	Date: 2005-02-04 18:35:23
	Subject: Re: libpq API incompatibility between 7.4 and 8.0