Thread: recompliing c-language functions with new releases of postgres
I have several c-language extensions to postgres that I distribute. I generally have to recompile my code with a new release of postgres, although sometimes it appears that it functions properly (passes my tests at least) without a recompile. Since my users are all on various releases of postgres, from 7.4.x to 8.1.x, I would like to minimize the number of versions of my code that I need to maintain and distribute. Presumably, the only reason I would HAVE TO recompile is when some header file changes. Is there any guarantee that header files DO NOT change, for example from 7.4.5 to 7.4.8 or even 7.4.12? Can I assume that header file changes only occur between major pg changes, such as 7.3 to 7.4, or 8.0 to 8.1? TJ
"TJ O'Donnell" <tjo@acm.org> writes: > Presumably, the only reason I would HAVE TO recompile > is when some header file changes. Is there any guarantee > that header files DO NOT change, for example from > 7.4.5 to 7.4.8 or even 7.4.12? Can I assume that header > file changes only occur between major pg changes, such as > 7.3 to 7.4, or 8.0 to 8.1? Uh, no, not really; see complaint from Thomas Hallgren in -hackers just yesterday. We don't normally change internal APIs in patch releases; in fact we don't change anything we don't have to. But we will change 'em if needed to fix a bug. You might want to eyeball the proposed "magic block" for loadable modules: http://archives.postgresql.org/pgsql-patches/2006-05/msg00124.php regards, tom lane
> > "TJ O'Donnell" <tjo@acm.org> writes: > >>> Presumably, the only reason I would HAVE TO recompile >>> is when some header file changes. Is there any guarantee >>> that header files DO NOT change, for example from >>> 7.4.5 to 7.4.8 or even 7.4.12? Can I assume that header >>> file changes only occur between major pg changes, such as >>> 7.3 to 7.4, or 8.0 to 8.1? > > > Uh, no, not really; see complaint from Thomas Hallgren in -hackers > just yesterday. We don't normally change internal APIs in patch > releases; in fact we don't change anything we don't have to. But > we will change 'em if needed to fix a bug. > > You might want to eyeball the proposed "magic block" for loadable > modules: > http://archives.postgresql.org/pgsql-patches/2006-05/msg00124.php > > regards, tom lane 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? I know in some software systems (and users complain about this) some bug fixes which would require API, or other major changes are postponed until the next major release. Maybe the changes Thomas Hallgren was pointing out in 8.1.4 are quite rare and we both realized at the same time that we were not in Utopia. As far as I can see, the "magic block" stuff would only work BETWEEN major releases, so this would not help me (much) or Thomas' 8.1.4+ woes. " It now only checks four things: Major version number (7.4 or 8.1 for example) NAMEDATALEN FUNC_MAX_ARGS INDEX_MAX_KEYS " TJ
"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