Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > bump major library version number?
>
> Were there any incompatible interface changes?
No, I don't _think_ so, but we have been bitten by this before, not
because of API change but because of use of libpgport functions called
by libpq in one release but not in a later one. What happened was that
apps pulled pgport functions from libpq and not from libpgport, and when
the calls were removed from libpq, the old apps didn't work anymore.
This hit us in 8.0.X.
Makefile.global has this now:
# Force clients to pull symbols from the non-shared library libpgport# rather than pulling some libpgport symbols from
libpqjust because# libpq uses those functions too. This makes applications less# dependent on changes in libpq's usage
ofpgport. To do this we link to# pgport before libpq. This does cause duplicate -lpgport's to appear# on client link
lines.ifdefPGXSlibpq_pgport = -L$(libdir) -lpgport $(libpq)elselibpq_pgport = -L$(top_builddir)/src/port -lpgport
$(libpq)endif
so I think we are OK going forward, but it something I wanted to keep an
eye out for. In older releases we actually had reports of failures, and
just told people to recompile, not realizing the magnitude of the
problem (it was assume to be more old CVS build issue than a
backward-compatible issue.) I am going to remove the open item about
this because I think if we had a problem, we would have heard about it
by now.
It is an interesting story because it does highlight that the libpq API
is not the only cause of a major bump.
-- 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,
Pennsylvania19073
