On Tue, Nov 11, 2014 at 12:33 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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.
The point is that there's nothing that you can do _PG_fini() that will
work correctly. If it does ExecutorRun_hook = prev_ExecutorRun, that's
fine if it's the most-recently-installed hook. But if it isn't, then
doing so corrupts the list.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
