> > 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
2.php"> ;-) + thread.
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2005-02-02 22:46:12|
|Subject: Re: FunctionCallN improvement. |
|Previous:||From: Alvaro Herrera||Date: 2005-02-02 22:04:04|
|Subject: Re: pg_dump bug in 7.3.9 with sequences|