[] 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.

Takayuki Tsunakawa

Reply via email to