> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > I'd like to document the policy clearly in the upgrade section of > PostgreSQL manual, eliminating any ambiguity, so that users can determine > what they should do without fear like "may or may not work". Which of the > following policies should I 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 changing the minor > > release, it's the bug of PostgreSQL. You can report it to > > pgsql-bugs.) > > That would not be a bug of PostgreSQL, the terms are incorrect. If there > is an API breakage, the extension needs to keep up in this case, so it would > be better to mention asking on the lists what may have gone wrong.
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. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
