From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Configuration Parameter/GUC value validation hook |
Date: | 2022-05-03 14:52:57 |
Message-ID: | CA+Tgmob9dXH9j4XaEfJJYsYNRvHuvQGQWM=-_MhxR7tO9u645w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 2, 2022 at 10:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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).
I don't think we should be in the business of encouraging vendors to
fork the source code, and I think it is quite likely that a vendor
will have better ideas than we do about what values they want to allow
their users to set. It's far easier to know what is reasonable in a
particular context than it is to make a statement about reasonableness
in general.
I have some desire here to see us solve this problem not just for
service providers, but for users in general. You don't have to be a
service provider to want to disallow SET work_mem = '1TB' -- you just
need to be a DBA on a system where such a setting will cause bad
things to happen. But, if you are a DBA on some random system, you
won't likely find a hook to be a particularly useful way of
controlling this sort of thing. I feel like Alice wants to do
something like GRANT work_mem BETWEEN '1MB' AND '2GB' to bob, not that
I'm proposing that particular syntax. I also don't have a clear idea
for what to do about GUCs where a range constraint isn't useful. One
could allow a list of permissible values, but that might not be
powerful enough. One could maybe allow a PL validation function for a
value, but that might be complicated to make work.
In the end, I don't think providing a hook here is particularly
unreasonable. I would be a little sad if it ended up being the only
thing we provided, but I'm also not a huge believer in the idea of
forcing people to write the patch that I want written as a condition
of writing the patch that they want written.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2022-05-03 15:19:01 | SQL/JSON: FOR ORDINALITY bug |
Previous Message | Daniel Gustafsson | 2022-05-03 14:50:29 | Re: testclient.exe installed under MSVC |