Re: [v9.5] Custom Plan API

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [v9.5] Custom Plan API
Дата
Msg-id CAA4eK1+zG6URD0KLegzALuUusRK_5sUN+nX+ucaqtfR71Q0nNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.5] Custom Plan API  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [v9.5] Custom Plan API  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Nov 10, 2014 at 6:33 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Nov 10, 2014 at 6:55 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > I thought that in general if user has the API to register the custom path
> > methods, it should have some way to unregister them and also user might
> > need to register some different custom path methods after unregistering
> > the previous one's.  I think we should see what Robert or others have to
> > say about this point before trying to provide such an API.
>
> I wouldn't bother.  As KaiGai says, if you want to shut the
> functionality off, the provider itself can provide a GUC.  Also, we
> really have made no effort to ensure that loadable modules can be
> safely unloaded, or hooked functions safely-unhooked.
> ExecutorRun_hook is a good example.  Typical of hook installation is
> this:
>
>         prev_ExecutorRun = ExecutorRun_hook;
>         ExecutorRun_hook = pgss_ExecutorRun;
>

In this case, Extension takes care of register and unregister for
hook.  In _PG_init(), it register the hook and _PG_fini() it
unregisters the same.  So if for custom scan core pg is
providing API to register the methods, shouldn't it provide an
API to unregister the same?


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: using custom scan nodes to prototype parallel sequential scan
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED