Re: Is a UDF binary portable across different minor releases and PostgreSQL distributions?
| От | Craig Ringer |
|---|---|
| Тема | Re: Is a UDF binary portable across different minor releases and PostgreSQL distributions? |
| Дата | |
| Msg-id | CAMsr+YGe9kuDEsaajpR4grt=1bW7rBH-UiT-yabSAPJgMwyFHQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Is a UDF binary portable across different minor releases and PostgreSQL distributions? ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
| Ответы |
Re: Is a UDF binary portable across different minor
releases and PostgreSQL distributions?
("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
|
| Список | pgsql-hackers |
On 1 July 2016 at 08:33, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.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.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Andreas SeltenreichДата:
Сообщение: Re: [sqlsmith] crashes in RestoreSnapshot on hot standby
Следующее
От: Andres FreundДата:
Сообщение: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <