Re: [HACKERS] [PATCH] Move all am-related reloption code intosrc/backend/access/[am-name] and get rid of relopt_kind for custom AM
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [PATCH] Move all am-related reloption code intosrc/backend/access/[am-name] and get rid of relopt_kind for custom AM |
Дата | |
Msg-id | CAB7nPqSvJug6XLzHJ898bZSu5DCgYgcWd0iEsdUU3BMXgvwXwg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Move all am-related reloption code intosrc/backend/access/[am-name] and get rid of relopt_kind for custom AM (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH] Move all am-related reloption code intosrc/backend/access/[am-name] and get rid of relopt_kind for custom AM
|
Список | pgsql-hackers |
On Tue, Nov 14, 2017 at 4:44 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Mon, Oct 30, 2017 at 9:49 AM, Nikolay Shaplov <dhyan@nataraj.su> wrote: >> В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал: >> >> Yet another git rebase. This patch can be applied to master branch again. >> >> For this patch no review needed now, as I will offer part of it (one that >> refuses to set toast reloptions when there is no TOAST table) as a separate >> patch. > > This patch needs a rebase, there are conflicts with HEAD. Bumping the patch to next CF as no updates have happened for the last two weeks. > There is still no API equivalent for add_int_reloption(), > add_real_reloption(), which is a problem as extension should be > allowed to still use that. Except if I am missing something you could > just have a compatibility API as for example optionCatalogAddItem() > and add_reloption() share really a lot. This worries me. -- Michael
В списке pgsql-hackers по дате отправления: