Re: libpq API incompatibility between 7.4 and 8.0

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> According to our RELEASE_CHANGES documentation:

> The major version number should be updated whenever the source of the
> library changes to make it binary incompatible. Such changes include,
> but are not limited to:

> 1. Removing a public function or 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.

Well, the point is that get_progname *isn't* a "public" function.
We never advertised it as a libpq entry point.

What this really brings out to me is that our development process
doesn't impose a very strong boundary between libpq and our bundled
client programs. If the client programs were enforced to use only the
documented public API of libpq then we'd not be having this discussion
--- but stuff such as libpgport support functions tends to slip by under
the radar. IIRC we've been bitten in exactly this way at least once
before. What I'm suggesting is that we just solve the whole class of
problems permanently, by abandoning the assumption that we're going to
guarantee binary compatibility across major releases. I don't think
that promise is really buying us anything very critical.

If we don't go that way, then we need to have some automatic check that
none of the client programs are using symbols they shouldn't be from
libpq. (Hmm ... will the existence of the Windows port help here?)

regards, tom lane