Re: Bumping libpq version number? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bumping libpq version number?
Date
Msg-id 200503111829.j2BITkt24876@candle.pha.pa.us
Whole thread Raw
In response to Bumping libpq version number?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Bumping libpq version number?  (Kurt Roeckx <kurt@roeckx.be>)
List pgsql-hackers
Kurt Roeckx wrote:
> On Fri, Mar 11, 2005 at 12:58:28PM -0500, Bruce Momjian wrote:
> > Are we still bumping the libpq major version number for 8.0.2?  I think
> > it is a bad idea because we will require too many client apps to be
> > recompiled, and we have had few problem reports.
> > 
> > We do need to bump the major version number for 8.1 and I am doing that
> > now.
> > 
> > One new problem I see is that changes to libpgport could affect client
> > apps that call libpq because they pull functions from pgport via libpq. 
> > For example, now that snprintf is called pg_snprintf, my initdb failed
> > in the regression tests because the the new initdb binary used
> > pg_snprintf but the installed libpq (ld.so.conf) didn't have it yet.
> 
> Does initdb call pg_snprintf directly?  Or does it call some
> libpq function that calls it?

With the current CVS, initdb calls pg_snprintf() on my platform which
doesn't support %$ natively on my libc printf.  Now, initdb could pull
from pgport itself but I think it pulled from libpq first.  Perhaps we
should reorder how those libraries appear in the link line but I think
that would fix just this case, not the more general one of pg client
apps.

> > The bottom line is that we only used to require major libpq version
> > bumps when we changed the libpq API.  Now, with libpgport, I am
> > concerned that changes in libpgport also will require a major version
> > bump.  This adds support to the idea that we will have to do a major
> > libpq bump for every major release.
> 
> Soname changes really should only happen in case of API or ABI
> changes and I think you really should try to avoid them.  I'm not
> sure why you think it's required now.

We had the problem with 8.0.X where we remove get_progname from libpq
and psql and friends were pulling that from libpq in the past for 7.4.

> Also, I think it's alot better to actually do soname changes to
> libraries if things can break.  I don't see having 2 library
> versions around as a problem.  And I'd rather have something I
> just know is not going to work.

Yes, that is where I am leaning in this discussion because libpgport
varies much more frequently than the libpq API.  However, changing the
link order should fix that so let me do that and see if it helps.

--  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
 


pgsql-hackers by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Data loss, vacuum, transaction wrap-around
Next
From: Hans-Jürgen Schönig
Date:
Subject: Re: Cost of XLogInsert CRC calculations