Обсуждение: Add a new function and a document page to get/show all the server hooks

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.

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