"Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> writes:
> I'd like to document the policy clearly in the upgrade section of PostgreSQL manual, eliminating any ambiguity, so
thatusers can determine what they should do without fear like "may or may not work". Which of the following policies
shouldI base on?
> Option 1:
> Rebuild UDFs with the target PostgreSQL distribution and minor release.
> Option 2:
> Rebuild UDFs with the target PostgreSQL distribution.
> You do not have to rebuild UDFs when you upgrade or downgrade the minor release. (If your UDF doesn't work after
changingthe minor release, it's the bug of PostgreSQL. You can report it to pgsql-bugs.)
I do not like either of those. We try hard not to break extensions in
minor releases, but I'm not willing to state it as a hard-and-fast policy
that we never will --- especially because there's no bright line as to
which internal APIs extensions can rely on or not. With sufficiently
negative assumptions about what third-party authors might have chosen to
do, it could become impossible to fix anything at all in released
branches.
In practice, extensions seldom need to be modified for new minor releases.
But there's a long way between that statement and a promise that it won't
ever happen for any conceivable extension.
To make this situation better, what we'd really need is a bunch of work
to identify and document the specific APIs that we would promise won't
change within a release branch. That idea has been batted around before,
but nobody's stepped up to do all the tedious (and, no doubt, contentious)
work that would be involved.
regards, tom lane