Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

Hi

2016-02-13 15:54 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On 10 February 2016 at 16:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Regards

Pavel

> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>