On Mon, Oct 7, 2019 at 9:56 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > We could imagine, maybe, that a hook for the purpose of allowing an > additional dimension to be considered would be essentially a path > comparison function, returning -1, +1, or 0 depending on whether > path A is dominated by path B (on this new dimension), dominates > path B, or neither. However, I do not see how multiple extensions > could usefully share use of such a hook.
Typically, we support hook-sharing mostly by ad-hoc methods: when installing a hook, you remember the previous value of the function pointer, and arrange to call that function yourself. That's not a great method. One problem with it is that you can't reasonably uninstall a hook function, which would be a nice thing to be able to do. We could do better by reusing the technique from on_shmem_exit or RegisterXactCallbacks: keep an array of pointers, and call them in order. I wish we'd retrofit all of our hooks to work more like that; being able to unload shared libraries would be a good feature. But if we want to stick with the ad-hoc method, we could also just have four possible return values: dominates, dominated-by, both, or neither. Still, this doesn't feel like very scalable paradigm, because this code gets called a lot. Unless both calling the hook functions and the hook functions themselves are dirt-cheap, it's going to hurt, and TBH, I wonder if even the cost of detecting that the hook is unused might be material. I wonder whether we might get a nicer solution to this problem if our method of managing paths looked less something invented by a LISP hacker, but I don't have a specific proposal in mind. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
