Re: Is a UDF binary portable across different minor releases and PostgreSQL distributions?

On 1 July 2016 at 08:33, Tsunakawa, Takayuki <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com
> wrote:

> Hello,
>
> While I was thinking of application binary compatibility between
> PostgreSQL releases, some questions arose about C language user-defined
> functions (UDFs) and extensions that depend on them.
>
> [Q1]
> Can the same UDF binary be used with different PostgreSQL minor releases?
> If it is, is it a defined policy (e.g. written somewhere 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 PostgreSQL 9.5.x without
> rebuilding?
>

Probably - but we don't guarantee it.

There's no formal extension API. So there's no boundary between "internal
stuff we might have to change to fix a problem" and "things extensions can
rely on not changing under them". In theory anything that changed behaviour
or changed a header file in almost any way could break an extension.

There's no deliberate breakage and some awareness of possible consequences
to extensions, but no formal process. I would prefer that the manual
explicitly recommend recompiling extensions against each minor update (or
updating them along with the packages), and advise that packagers make
their extensions depend on an = minor version in their package
specifications, not a >= .

However, in practice it's fine almost all the time.

I think making this more formal would require, as Tom noted, a formal
extension API we can promise to maintain, likely incorporating:

- fmgr
- datatype functions and macros
- elog and other core infrastructure
- major shmem structures
- GUC variables
- plan nodes and command structs
- SPI
- replication origins
- bgworkers
- catalog definitions
- ... endlessly more

To actually ensure extensions conform to the API we'd probably have to
build with -fvisibility=hidden (gcc) and on Windows change our .def
generation, so we don't expose anything that's not part of the formal API.
That's a very strict boundary though; there's no practical way an extension
can say "I know what I'm doing, gimme the internals anyway" and reach
through it. I'd prefer a soft boundary that spat warnings when you touch
stuff you're not allowed to, but I don't know of any good way to do that
that works across multiple compilers and toolchains.

We'd almost certainly have to allow ourselves to _expand_ the API in minor
releases since otherwise the early introduction of the formal API would be
a nightmare. That's fine on pretty much every platform though.

The main thing is that it's a great deal of work for limited benefit. I
don't know about you, but I'm not keen.

> 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?
>

Not especially safely.

If you verified that all the compiler flags were the same and your
extension doesn't transitively bundled reference libraries that might be
different and incompatible versions (notably gettext, which Pg exposes in
its own headers) ... you're probably OK.

Again, in practice it generally works, but I wouldn't recommend it. Nor is
this something we can easily address with an extension API policy.

> How about other distributions which probably don't modify the source
> code? Should the UDF be built with the target PostgreSQL because configure
> options may differ, which affects data structures

Yeah. And exposed ABI. I don't recommend it.

It's probably safe-ish on MS Windows, which is designed to allow greater
compatibility between executables built with differing toolchains and
options. I wouldn't do it on any unix.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services