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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.
Дата
Msg-id 20163.1455375247@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
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.)
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: extend pgbench expressions with functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Crash with old Windows on new CPU