From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Configuration Parameter/GUC value validation hook |
Date: | 2022-05-02 14:54:45 |
Message-ID: | 1845018.1651503285@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
> I propose to add a simple new hook in set_config_option (void
> set_config_option_hook(struct config_generic *record);) and the
> vendors can implement their own platform-dependent extensions to
> accept or reject certain parameters (based on platform/VM
> configuration) that are of interest to them.
This seems entirely useless. Vendors are unlikely to have any better
idea than we do about what are "reasonable" values. Moreover, if they
did, modifying the source code directly would be an easier route to
introducing their code than making use of a hook (which'd require
finding a way to ensure that some extension is loaded).
In general, I think you need a much more concrete use-case than this
before proposing a new hook. Otherwise we're going to have tons of
hooks that we don't know whether they're actually useful or being
used by anyone.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2022-05-02 14:56:16 | Re: strange slow query - lost lot of time somewhere |
Previous Message | Peter Eisentraut | 2022-05-02 14:53:34 | Re: Proposal for internal Numeric to Uint64 conversion function. |