From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@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. Regards Takayuki Tsunakawa
