Re: allowing for control over SET ROLE - Mailing list pgsql-hackers

From igor levshin
Subject Re: allowing for control over SET ROLE
Date
Msg-id 142af054-c06b-d77a-e362-c229ff0bfc3a@postgrespro.ru
Whole thread Raw
In response to Re: allowing for control over SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
идея и её реализация насчёт Параллельного чтения - как вам? Мне 
показалось, интересно и полезно. Но это, думаю, одноразовая акция. 
Времени и сил на это довольно много ухлопал, хотя вроде дело нехитрое 
:)  Стоило?

15.11.2022 20:07, Robert Haas пишет:
> Bump.
>
> Discussion has trailed off here, but I still don't see that we have a
> better way forward here than what I proposed on September 30th. Two
> people have commented. Nathan said that he wasn't sure this was best
> (neither am I) but that he didn't have a better idea either (neither
> do I). Stephen proposed decomposing ADMIN OPTION, which is not my
> preference, but even if it turns out that we want to pursue that
> approach, I do not think it would make sense to bundle that into this
> patch, because there isn't enough overlap between that change and this
> change to justify that treatment.
>
> If anyone else wants to comment, or if either of those people want to
> comment further, please speak up soon. Otherwise, I am going to press
> forward with committing this. If we do not, we will continue to have
> no way of restricting of SET ROLE, and we will continue to have no way
> of preventing the creation of objects owned by predefined roles by
> users who have been granted those roles. As far as I am aware, no one
> is opposed to those goals, and in fact I think everyone who has
> commented thinks that it would be good to do something. If a better
> idea than what I've implemented comes along, I'm happy to defer to it,
> but I think this is one of those cases in which there probably isn't
> any totally satisfying solution, and yet doing nothing is not a
> superior alternative.
>
> Thanks,
>



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Catalog_xmin is not advanced when a logical slot is lost
Next
From: Alvaro Herrera
Date:
Subject: Re: MERGE regress test