Re: Possibility to disable `ALTER SYSTEM`
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Tom Lane <tgl@sss.pgh.pa.us>, "David G. Johnston" <david.g.johnston@gmail.com>, Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Martín Marqués <martin.marques@gmail.com>, Isaac Morland <isaac.morland@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-02-07T13:49:01Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add allow_alter_system GUC.
- d3ae2a24f265 17.0 landed
-
Rename COMPAT_OPTIONS_CLIENT to COMPAT_OPTIONS_OTHER.
- de7e96bd0fc6 17.0 landed
-
Remove support for version-0 calling conventions.
- 5ded4bd21403 10.0 cited
On Wed, 7 Feb 2024 at 11:35, Gabriele Bartolini <gabriele.bartolini@enterprisedb.com> wrote: > This is mostly the approach I have taken in the patch, except allowing to change the value in the configuration file. (I had missed the patch in the long thread). I think it would be nice to have this be PGC_SIGHUP, and set GUC_DISALLOW_IN_AUTO_FILE. That way this behaviour can be changed without shutting down postgres (but not with ALTER SYSTEM, because that seems confusing). > but wasn't sure in which `config_group` to place the 'enable_alter_system` GUC, based on the src/include/utils/guc_tables.h. Any thoughts/hints? I agree that none of the existing groups fit particularly well. I see a few options: 1. Create a new group (maybe something like "Administration" or "Enabled Features") 2. Use FILE_LOCATIONS, which seems sort of related at least. 3. Instead of adding an "enable_alter_system" GUC we would add an "auto_config_file" guc (and use the FILE_LOCATIONS group). Then if a user sets "auto_config_file" to an empty string, we would disable the auto config file and thus ALTER SYSTEM. I'd prefer 1 or 3 I think. I kinda like option 3 for its consistency of being able to configure other config file locations, but I think that would be quite a bit more work, and I'm not sure how useful it is to change the location of the auto file.