Re: allowing for control over SET ROLE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing for control over SET ROLE
Date: 2022-11-17 21:52:29
Message-ID: CA+TgmoYwVmk1VPb5ZV6aLAchRs80Dd2h3X3w49rPncqVojMJng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2022 at 7:23 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Tue, 2022-11-15 at 12:07 -0500, Robert Haas wrote:
> > If anyone else wants to comment, or if either of those people want to
> > comment further, please speak up soon.
>
> Did you have some thoughts on:
>
> https://postgr.es/m/a41d606daaaa03b629c2ef0ed274ae3b04a2c266.camel@j-davis.com

I mean, I think what we were discussing there could be done, but it's
not the approach I like best. That's partly because that was just a
back-of-the-envelope sketch of an idea, not a real proposal for
something with a clear implementation path. But I think the bigger
reason is that, in my opinion, this proposal is more generally useful,
because it takes no position on why you wish to disallow SET ROLE. You
can just disallow it in some cases and allow it in others, and that's
fine. That proposal targets a specific use case, which may make it a
better solution to that particular problem, but it makes it unworkable
as a solution to any other problem, I believe.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-11-17 21:54:27 Strange failure on mamba
Previous Message Daniel Gustafsson 2022-11-17 21:16:19 Outdated url to Hunspell