From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Craig Ringer 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 >= .
Yes, I think such recommendation in the manual is the best.
However, in practice it's fine almost all the time.
Maybe most extensions don’t use sensitive parts of the server…
I think making this more formal would require, as Tom noted, a formal extension API we can promise to maintain, likely incorporating:
- ... endlessly more
Endless (^^;)
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.
I’m not keen, either… I don’t think I can form the API that advanced extension developers will be satisfied with. I’ll just document the compabibility article in the upgrade section.
