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
