Re: recompliing c-language functions with new releases of postgres - Mailing list pgsql-general

From Tom Lane
Subject Re: recompliing c-language functions with new releases of postgres
Date
Msg-id 7050.1148520982@sss.pgh.pa.us
Whole thread Raw
In response to Re: recompliing c-language functions with new releases of postgres  (TJ O'Donnell <tjo@acm.org>)
List pgsql-general
"TJ O'Donnell" <tjo@acm.org> writes:
> I understand and appreciate bug fixes, but isn't one of the purposes of
> major releases to provide some stability (say of API) within
> the major release?

Our traditional definition of API stability within a release series has
considered only the SQL level: no forced initdbs, no changes of
SQL-level semantics (at least not without darn good reason).  Providing
stability of backend-internal APIs has not been on the radar screen at all.

I'm entirely unwilling to buy into a proposal that reads "no .h file
changes within a release series".  To make this fly, there'd need to be
a clear, and rather narrow, definition of which aspects of the backend
internal environment are considered API exported for add-ons to use.
Which would be a good thing to have, really, but even developing a
proposal would be a huge amount of work (never mind getting everyone
to agree to it ;-)).  Are you volunteering?

BTW, this seems pretty far off-topic for -general; I suggest using
-hackers for further discussion.

            regards, tom lane

pgsql-general by date:

Previous
From: TJ O'Donnell
Date:
Subject: Re: recompliing c-language functions with new releases of postgres
Next
From: Tom Lane
Date:
Subject: Re: 8.1.4: Who says "PHP deprecated addslashes since 4.0"?