On Tue, Nov 11, 2014 at 12:33 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Nov 10, 2014 at 6:33 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Mon, Nov 10, 2014 at 6:55 AM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
