On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> [Q1]
> Can the same UDF binary be used with different PostgreSQL minor releases? If it is, is it a defined policy (e.g.
writtensomewhere in the manual, wiki, documentation in the source code)?
>
> For example, suppose you build a UDF X (some_extension.so/dll) with PostgreSQL 9.5.0. Can I use the binary with
PostgreSQL9.5.x without rebuilding?
Yes, that works properly. There could be problems with potential
changes in the backend APIs in a stable branch, but this usually does
not happen much.
> Here, the UDF references the contents of server-side data structures, like pgstattuple accesses the members of
HeapScanData. If some bug fix of PostgreSQL changes the member layout of those structures, the UDF binary would
possiblymisbehave. Basically, should all UDFs be rebuilt with the new minor release?
Not necessarily.
> Or, are PostgreSQL developers aware of such incompatibility and careful not to change data structure layout?
Committers are aware and careful about that, that's why exposed APIs
and structures are normally kept stable. At least that's what I see.
> [Q2]
> Can the same UDF binary be used with different PostgreSQL distributions (EnterpriseDB, OpenSCG, RHEL packages, etc.)?
Or should the UDF be built with the target distribution?
Each distribution has usually its own compilation options (say page
size, etc.) even if I recall that most of them use the defaults, so it
clearly depends on what kind of things each of them uses. I would
recommend a recompilation just to be safe. It may not be worth
spending time at looking and checking each one's differences.
> I guess the rebuild is necessary if the distribution modified the source code of PostgreSQL. That is, the UDF binary
builtwith the bare PostgreSQL cannot be used with EnterpriseDB's advanced edition, which may modify various data
structures.
That's for sure.
> How about other distributions which probably don't modify the source code? Should the UDF be built with the target
PostgreSQLbecause configure options may differ, which affects data structures?
It depends on how they build it, but recompiling is the safest bet to
avoid any surprises... I recall seeing an extension code that caused a
SIGSEV with fclose(NULL) on SLES and only reported an error with
Ubuntu. The code was faulty in this case.. But recompiling is usually
a better bet of stability.
--
Michael