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