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

Yes, it will. At least it will refuse to link with references that are
not in the libpqdll.def file. It won't change if the *signature* of the
functions change.

<flashback
href="http://archives.postgresql.org/pgsql-hackers-win32/2004-10/msg0004
2.php"> ;-) + thread.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend