From: | Matthias Kurz <m(dot)kurz(at)irregular(dot)at> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Add read-only param to set_config(...) / SET that effects (at least) customized runtime options |
Date: | 2018-04-20 13:55:49 |
Message-ID: | CAO=2mx5OHkF_UY5fC4x22vbYyicLaY3po3OxYt1YKccEf9EjUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
in MS SQL Server you are able to make an entry of SESSION_CONTEXT read-only
by passing the @read_only param to the sp_set_session_context function:
"[ @read_only= ] { 0 | 1 } A flag of type bit. If 1, then the value for the
specified key cannot be changed again on this logical connection. If 0
(default), then the value can be changed."
See
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-set-session-context-transact-sql
I propose the same functionally for PostgreSQL - at least when setting
"customized options" (the ones with a dot in the name:
https://www.postgresql.org/docs/10/static/runtime-config-custom.html)
The set_config(...) method therefore would end up like:
set_config(setting_name, new_value, is_local, read_only)
The equalient SET command could look something like:
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.
When setting read-only for a transaction config "the effects of the SET
LOCAL command disappear at function exit" will still be true, like written
in https://www.postgresql.org/docs/10/static/sql-set.html.
What do you think?
Regards,
Matthias
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-04-20 13:58:06 | Re: SHOW ALL does not honor pg_read_all_settings membership |
Previous Message | Tom Lane | 2018-04-20 13:44:28 | Re: Postgresql9.6 type cache invalidation issue - different behave of psql and pg regress |