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

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

Responses

Browse pgsql-hackers by date

  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