Re: Resource Owner reassign Locks

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Resource Owner reassign Locks
Дата
Msg-id CAMkU=1x94AP2HXGm1q6z2KqmzURTDDurnhfwNibPcPNcA5CrPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Resource Owner reassign Locks  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Resource Owner reassign Locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund <andres@anarazel.de> wrote:
> On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes <jeff.janes@gmail.com> wrote:
>
>>Unfortunately I don't know what that means about the API.  Does it mean
>>that none of the functions declared in any .h file can have their
>>signatures changed?  But new functions can be added?
>
> That's the safest way. Sometimes you can decide that a function can not sanely be called by external code and thus change the signature. But I'd rather not risk or here, IRS quite possible that one pod these is used by a extension.

Where are we on this? Could there be a version for <= 9.2?

Once the code has to be rewritten, my argument that it has been working "in the field" for a while doesn't really apply anymore.  It is beyond what I feel comfortable trying to do, especially as I have no "test case" of 3rd party code to verify I haven't broken it.

I still think is a good idea, but for someone who knows more about linkers and .so files than I do.

If I were faced with upgrading a 9.2 instance with many tens of thousands of objects, I would just backpatch the existing code and compile it to make a binary used only for the purposes of the upgrade.

Cheers,

Jeff

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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Error message with plpgsql CONTINUE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Rework access method interface