Hi,
On 2020-09-28 09:09:24 +0530, Abhijit Menon-Sen wrote:
> postgres=# SET search_path += octopus;
> SET
Yea, that would be quite useful!
> The second patch
> (0002-Support-SET-syntax-for-numeric-configuration-setting.patch) adds
> support to modify numeric configuration settings:
>
> postgres=# SET cpu_tuple_cost += 0.02;
> SET
> postgres=# SET effective_cache_size += '2GB';
> SET
> postgres=# SHOW effective_cache_size;
> ┌──────────────────────┐
> │ effective_cache_size │
> ├──────────────────────┤
> │ 6GB │
> └──────────────────────┘
> (1 row)
> postgres=# ALTER SYSTEM SET max_worker_processes += 4;
> ALTER SYSTEM
Much less clear that this is a good idea...
It seems to me that appending and incrementing using the same syntax is
a) confusing b) will be a limitation before long.
> These patches do not affect configuration file parsing in any way: its
> use is limited to "SET" and "ALTER xxx SET".
Are you including user / database settings as part of ALTER ... SET? Or
just SYSTEM?
I'm not convinced that having different features for the SQL level is a
good idea.
> (Another feature that could be implemented using this framework is to
> ensure the current setting is at least as large as a given value:
>
> ALTER SYSTEM SET shared_buffers >= '8GB';
Given that this is just SQL level, I don't see why we'd need a special
type of language here. You can just use DO etc.
Greetings,
Andres Freund