Re: Add read-only param to set_config(...) / SET that effects (at least) customized runtime options

On 04/20/2018 09:55 AM, Matthias Kurz wrote:

> SET READONLY my_app.some_var = 'foo';
> SET READONLY SESSION my_app.some_var = 'foo';
> SET READONLY LOCAL my_app.some_var = 'foo';
>
> Of course read-only would default to false for backwards compatibility.
> When setting READONLY for on SESSION config then that config is not allowed
> to be changed anymore until the connection gets closed - even when running
> RESET ALL or DISCARD ALL.

There may be considerable overlap here with the idea of
cookie-protected settings discussed back in

https://www.postgresql.org/message-id/59127E4E.8090705%40anastigmatix.net

At one point in that thread was a suggestion to look at proposals
for "secure variables" or "package variables" that were pending,
but I didn't see anything then to convince me those proposals
addressed the same use case.

There's also a thing called "schema variables" currently registered
in the 2018-09 commitfest, but I haven't really seen how it would
serve the same purpose either.

https://commitfest.postgresql.org/18/1608/

But the cookie-protected idea in the first link seems easy to
implement and was aimed at the same purpose you seem to have here:
nail down some setting in advance of running some code you don't
want changing it.

It seemed to me at the time to be not hard to implement, even just
as an extension for proof of concept. One small obstacle is that the
check hook on a variable doesn't get called during attempted RESET,
so the only way to block a prohibited RESET would have to be from
an assign hook, which isn't expected to fail. It could surely throw
an error, but which would mess up the whole RESET, but might be
tolerable.

I had been thinking to implement such an extension. I haven't worked
on it, but might yet. It would be simplest for it to exercise such
control over variables the extension itself defines. Not so easy
to protect other variables (poking a new check hook or assign hook
into an existing variable definition isn't practical, as those are
on a list that's static within guc.c).

But if you are only concerned about custom options, the needed
pieces might already exist.

-Chap