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
