Re: "20.16. Customized Options" – cannot be set by `ALTER SYSTEM`

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Mon, 2023-10-16 at 12:29 -0400, Tom Lane wrote:
>> So that feels like a bug: we should not allow ALTER SYSTEM to execute
>> against a placeholder GUC definition, because the placeholder can't
>> tell us whether the value is valid.  I wonder though if forbidding
>> this would break any legitimate usage patterns.

> I feel the same. However, the lack of any "variables" in SQL (as proposed
> in [1]) leads a lot of people to abuse placeholder parameters as variables
> to hold application state. I am sure that that is where this complaint
> comes from. We maintain that doing so is not a valid use case, but that claim
> sounds increasingly like a grammarian declaring that sentences should not
> end with a preposition, when everybody does it all the time.

Yeah, and we have been slowly removing the issues that made us not want
to recommend using them like that.

Anyway, I realized that I was wrong to claim that we need ALTER SYSTEM
to defend us against bogus values of extension parameters in the config
file. Checking is an important thing to do for core parameters, but
a faulty extension parameter doesn't stop the system from booting.
That's because we'll apply all the config file entries before we load
any extensions, even ones listed in shared_preload_libraries. When
we do load an extension, if it doesn't like what it finds in a placeholder
then you get a WARNING and the parameter's default value is substituted.
So there's no risk of an unstartable system.

So maybe we should allow ALTER SYSTEM for unrecognized parameters,
as long as the parameter name is syntactically legit and you're a
superuser.

regards, tom lane