Re: libpq API incompatibility between 7.4 and 8.0

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > We can rectify the mistake, but then we need to change the SONAME.  
> > That's what it's for.
> 
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
> 
> This brings up a point that I think has been discussed before: we
> operate on the assumption that incrementing SO_MINOR_VERSION is enough
> to distinguish different releases of libpq, but in point of fact it
> is not.  The Linux conventions for library names, for one, essentially
> require us to bump SO_MAJOR_VERSION for every release if we want to have
> any hope of letting different versions coexist.  Perhaps our convention
> should be to bump SO_MAJOR_VERSION for each of our major releases and
> only use SO_MINOR_VERSION when we change a library in a dot-release.

According to our RELEASE_CHANGES documentation:The major version number should be updated whenever the source of
thelibrarychanges to make it binary incompatible. Such changes include,but are not limited to:1. Removing a public
functionor structure (or typedef, enum, ...)2. Modifying a public functions arguments.3. Removing a field from a public
structure.

so while I don't think we need to update the major number for every
PostgreSQL major release, the removal of prog_name probably required a
major bump.

Oops.

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