Re: Add a new function and a document page to get/show all the server hooks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add a new function and a document page to get/show all the server hooks
Date: 2022-05-04 14:00:18
Message-ID: 2338837.1651672818@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-05-04 14:05:45 Re: configure openldap crash warning
Previous Message Peter Eisentraut 2022-05-04 13:56:13 Re: bogus: logical replication rows/cols combinations