Tom Lane wrote:
> 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.

psql actually calls get_progname(). Do we know that it will try to link
in the other functions from path.c? I am unsure.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match