From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Abhijit Menon-Sen <ams(at)toroid(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] SET search_path += octopus |
Date: | 2020-10-20 18:32:51 |
Message-ID: | 656463.1603218771@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-10-20 14:16:12 -0400, Tom Lane wrote:
>> I'd make that point against the whole proposal. There's nothing here that
>> can't be done with current_setting() + set_config().
> The one case where I can see SET support being useful even without
> config support is to allow for things like
> ALTER DATABASE somedatabase SET search_path += 'myapp';
Hmm, yeah, that's fractionally less easy to build from spare parts
than the plain SET case.
But I think there are more definitional hazards than you are letting
on. If there's no existing pg_db_role_setting entry, what value
exactly are we += 'ing onto, and why?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-10-20 18:33:58 | Re: [PATCH] SET search_path += octopus |
Previous Message | Andres Freund | 2020-10-20 18:23:37 | Re: [PATCH] SET search_path += octopus |