Thread: Add a new function and a document page to get/show all the server hooks
Add a new function and a document page to get/show all the server hooks
From
Bharath Rupireddy
Date:
Hi, As we have many hooks in postgres that extends the postgres functionality, I'm wondering if it's a good idea to add a new function, say, pg_get_all_server_hooks, returning hook name, hook declaration and its current value (if there's any external module loaded implementing the hook). This basically helps to know at any given point of time what all the hooks are installed and the modules implementing them. Imagine using this new function on a production server with many supported extensions installed which might implement some of the hooks. Also, a dedicated page in the documentation listing out all the hooks, their declarations and a short description. This will help developers/users to know the available hooks. One problem is that the new function and doc page create an extra burden of keeping them up to date with the hooks modifications and new hook additions, but I think that can be taken care of in the review phases. Thoughts? Regards, Bharath Rupireddy.
Re: Add a new function and a document page to get/show all the server hooks
From
Peter Eisentraut
Date:
On 04.05.22 12:54, Bharath Rupireddy wrote: > One problem is that the new function and doc page create an extra > burden of keeping them up to date with the hooks modifications and new > hook additions, but I think that can be taken care of in the review > phases. > > Thoughts? I think this has been proposed a number of times and rejected.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > On 04.05.22 12:54, Bharath Rupireddy wrote: >> One problem is that the new function and doc page create an extra >> burden of keeping them up to date with the hooks modifications and new >> hook additions, but I think that can be taken care of in the review >> phases. > I think this has been proposed a number of times and rejected. The most recent such discussion was here: https://www.postgresql.org/message-id/flat/20201231032813.GQ13234%40fetter.org The basic point was that there's a pretty low bar to creating a hook, but the more infrastructure you want to have around hooks the harder it will be to add any ... and the less likely that the infrastructure will be kept up-to-date. My takeaway from that thread was that there could be support for minimalistic documentation, along the lines of a README file listing all the hooks. I'm not in favor of trying to do more than that --- in particular, the cost/benefit ratio for the function proposed here seems to approach infinity. regards, tom lane