Re: recompliing c-language functions with new releases of postgres

>
> "TJ O'Donnell" <tjo(at)acm(dot)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