On Fri, Jul 1, 2016 at 11:33 AM, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > 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 different shape. 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: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/postgresql 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. -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers