On Fri, Jul 1, 2016 at 11:33 AM, Tsunakawa, Takayuki
> OK, I understood that your choice is option 2. And the UDF developer should
> report the problem and ask for its reason on pgsql-bugs, possibly end up
> haveing to rebuild the UDF. But if so, it sounds like option 1. That is,
> "For safety, rebuild your UDF with each minor release. That way, you can
> avoid severe problems that might take time to pop up above water." I wonder
> if this is similar to the Linux's loadable kernel modules.
> I'd like to hear opinions from other decision makers here before proceeding,
> as well as Michael.
Speaking of some past experience, I got once bitten the change of
signature of IndexDefine() done in 820ab11 with 9.2, because at some
point, the tree I was maintaining kept a static copy of Postgres code,
and bootparse.c (!) was in the set. Guess the result. That was a lot
of fun to debug to find why Postgres kept crashing at initdb, and
extensions could blow up similarly if they expect routines with a
Since then I take it on the safest side and all my in-house backend
extensions get recompiled, for each minor releases, as well as each
point in-between. So that's clearly the option 1, I get to do in for
the internal stuff I work on.
Even if there is a list of routines that are listed as in the docs
telling that those will not get broken, in some cases it is really
hard to not break that promise. Looking at for example the diffs of
820ab11, my guess is that there has been a lot of discussions around
this change, and at the end the signature of DefineIndex had to
change, for the best.
Now, speaking from the heart, it is somewhat a waste to have to
recompile that all the time... But by looking at any package
maintainer history, for example that, there are rebuilds triggered
from time to time because of changes of dependent libraries like
OpenSSL. Take here for example:
So perhaps the best answer, is not 1 nor 2. Just saying that the
routines are carefully maintained with a best effort, though sometimes
you may need to rebuild depending on unavoidable changes in routine
signatures that had to be introduced.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: