Chao Li <li.evan.chao@gmail.com> writes:
>> On Sep 23, 2026, at 17:44, Yuhang Qiu <iamqyh@gmail.com> wrote:
>> For configuration parameters that can be reloaded, administrators often need
>> to perform two steps in succession:
>> ```sql
>> ALTER SYSTEM SET work_mem = '64MB';
>> SELECT pg_reload_conf();
>> ```
>>
>> I propose adding `ALTER SYSTEM RELOAD`, so the sequence can be written as:
>> ```sql
>> ALTER SYSTEM SET work_mem = '64MB';
>> ALTER SYSTEM RELOAD;
>> ```
> Thanks for the patch. After reading it, I have a concern. pg_reload_conf() relies on normal function privileges, so a
superuser can grant EXECUTE on it to a non-superuser. With this patch, the two interfaces for doing essentially the
samething would have different privilege models:
I'm pretty down on this proposal even without the privilege question.
"There's more than one way to do it" isn't a great thing for
security-relevant operations, and this surely is one.
Also, I don't like the loss of an explainable scope for what
ALTER SYSTEM does. I see the patch changes the command's summary
like so:
<refname>ALTER SYSTEM</refname>
- <refpurpose>change a server configuration parameter</refpurpose>
+ <refpurpose>change or reload the server configuration</refpurpose>
which is entirely not self-consistent. (For one thing, it implies
that you can change any part of the server's configuration through
this command, which is not so: stuff like pg_hba.conf remains out
of scope.)
This lack of intellectual consistency would get ten times worse
if we followed through on the idea of overloading ALTER SYSTEM
with unrelated actions like log rotation and promotion.
The reason ALTER SYSTEM exists, IMO, is to re-use the infrastructure
we had for SET and RESET commands to allow alteration of GUC values
system-wide as well as locally in a session. It does not exist for
discoverability.
regards, tom lane
