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
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 |