Re: [PATCH] SET search_path += octopus

From: Andres Freund <andres(at)anarazel(dot)de>
To: Abhijit Menon-Sen <ams(at)toroid(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] SET search_path += octopus
Date: 2020-10-20 17:53:04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2020-09-28 09:09:24 +0530, Abhijit Menon-Sen wrote:
> postgres=# SET search_path += octopus;

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;
> postgres=# SET effective_cache_size += '2GB';
> postgres=# SHOW effective_cache_size;
> ┌──────────────────────┐
> │ effective_cache_size │
> ├──────────────────────┤
> │ 6GB │
> └──────────────────────┘
> (1 row)
> postgres=# ALTER SYSTEM SET max_worker_processes += 4;

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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-10-20 18:16:12 Re: [PATCH] SET search_path += octopus
Previous Message Tom Lane 2020-10-20 16:25:48 Re: Non-configure build of thread_test has been broken for awhile