Simon Riggs <simon@2ndQuadrant.com> writes: > On 10 February 2016 at 16:36, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> FWIW, I wasn't paying attention either, but I'm convinced by Robert's >> argument. Avoiding coupling between extensions is worth an API break.
> Old APIs - why can't we keep it?
Because with the old API, a bug in extension A may go unnoticed in A's testing but break when it's combined with extension B. That causes headaches all around, not just to the extension authors but to their users. The new API ensures detection of didn't-request-enough-locks bugs regardless of which other extensions are installed. That is worth the cost of a forced API update, in Robert's judgement and mine too.
(Having said that, I wonder if we could put back the old API as a shim layer *without* the allocate-some-excess-locks proviso. That would get us to a situation where standalone testing of a broken extension would disclose its bug, without breaking non-buggy extensions.)
If there will be simple way, how to fix it, then I'll fix my extensions. But new API is working only when the extension has own share memory segment. For some complex extensions like Orafce it means expensive refactoring.
What is worst, this refactoring is difficult now, because I support older versions when I have not private shared segments.
