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

From Kurt Roeckx
Subject Re: Bumping libpq version number?
Date
Msg-id 20050311182110.GA26120@roeckx.be
Whole thread Raw
In response to Bumping libpq version number?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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?

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

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.


Kurt



pgsql-hackers by date:

Previous
From: Kurt Roeckx
Date:
Subject: Re: Bumping libpq version number?
Next
From: Mark Shewmaker
Date:
Subject: Re: [BUGS] We are not following the spec for HAVING without GROUP BY