| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | tjo(at)acm(dot)org |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: recompliing c-language functions with new releases of postgres |
| Date: | 2006-05-25 01:36:22 |
| Message-ID: | 7050.1148520982@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"TJ O'Donnell" <tjo(at)acm(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | nuno | 2006-05-25 02:11:33 | Re: column order |
| Previous Message | TJ O'Donnell | 2006-05-25 01:05:42 | Re: recompliing c-language functions with new releases of postgres |