Hi!
On Fri, 28 Apr 2023 at 17:42, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> On 4/27/23 8:04 PM, Alexander Korotkov wrote:
> > On Fri, Apr 28, 2023 at 2:30 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> >> Additionally, I think if we start recording role OID, then we need a
> >> full set of management clauses for each individual option ownership.
> >> Otherwise, we would leave this new role OID without necessarily
> >> management facilities. But with them, the whole stuff will look like
> >> awful overengineering.
> >
> > I can also predict a lot of ambiguous cases. For instance, we
> > existing setting can be overridden with a different role OID. If it
> > has been overridden can the overwriter turn it back?
>
> [RMT hat]
>
> While the initial bug has been fixed, given there is discussion on
> reverting 096dd80f3, I've added this as an open item.
>
> I want to study this a bit more before providing my own opinion on revert.
I see that 096dd80f3 is a lot simpler in implementation than
a0ffa885e, so I agree Alexander's opinion that it's good not to
overengineer what could be done simple. If we patched corner cases of
a0ffa885e before (by 13d838815), why not patch minor things in
096dd80f3 instead of reverting?
As I see in [1] there is some demand from users regarding this option.
Regards,
Pavel Borisov,
Supabase.