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
