On Fri, Mar 31, 2023 at 3:36 AM Jeff Davis <pg...@j-davis.com> wrote: > That's moving the goalposts a little, though: > > "Some concern was expressed ... might break things that are currently > working..." > > https://www.postgresql.org/message-id/CA+TgmoaE35kKS3-zSvGiZszXP9Tb9rNfYzT=+fo8ehk5edk...@mail.gmail.com > > If the original use case was "don't break stuff", I think patch 0002 > solves that, and we don't need this special case in 0001. Would you > agree with that statement?
I think that's too Boolean. The special case in 0001 is a better solution for the cases where it works. It's both more granular and more convenient. The fact that you might be able to get by with 0002 doesn't negate that. > > But I imagine CREATE SUBSCRIPTION being used either by > > superusers or by people who already have those role grants anyway, > > because I imagine replication as something that a highly privileged > > user configures on behalf of everyone who uses the system. And in > > that > > case those role grants aren't something new that you do specifically > > for logical replication - they're already there because you need them > > to administer stuff. Or you're the superuser and don't need them > > anyway. > > Did the discussion drift back towards the SET ROLE in the other > direction? I thought we had settled that in v16 we would require that > the subscription owner can SET ROLE to the table owner (as in your > current 0001), but that we could revisit it later. Yeah, I think that's what we agreed. I'm just saying that I'm not as concerned about that design as you are, and encouraging you to maybe not be quite so dismayed by it. -- Robert Haas EDB: http://www.enterprisedb.com
