On Fri, Mar 24, 2023 at 3:17 AM Jeff Davis <pg...@j-davis.com> wrote: > The current patch (non-superuser-subscriptions) is the most user-facing > aspect, and it seems wrong to commit it before we have the security > model in a reasonable place. As you pointed out[1], it's not in a > reasonable place now, so encouraging more use seems like a bad idea.
I certainly agree that the security model isn't in a reasonable place right now. However, I feel that: (1) adding an extra predefined role doesn't really help, because it doesn't actually do anything in and of itself, it only prepares for future work, and (2) even adding the connection string security stuff that you're proposing doesn't really help, because (2a) connection string security is almost completely separate from the internal security considerations addressed in the message to which you linked, and (2b) in my opinion, there will be a lot of people who won't use that connection string security stuff even if we had it, possibly even a large majority of people won't use it, because it responds to a specific use case which I think a lot of people don't have, and (3) I don't agree either that this patch would encourage more use of logical replication or that it would be bad if it did. I mean, there could be someone who knows about this patch and will hesitate to deploy logical replication if it doesn't get committed, or maybe slightly more likely, won't be able to do so if this patch doesn't get committed because they're running in a cloud environment. But probably not. Cloud providers are already hacking around this problem, Microsoft included. As a community, we're better off having a standard solution in core than having every vendor hack it their own way. And outside of a cloud environment, there's not really any reason for the lack of this patch to make a potential user hesitate. Also, features getting used is a thing that I think we should all want. If logical replication is in such a bad state that we think people should be using it, we should rip it out until the issues are fixed. I don't think anyone would seriously propose that such a course of action is advisable. So the alternative is to make it better. To reiterate what I think the most important point here is, both Azure and AWS already let you do this. EDB's own cloud offering is also going to let you do this, whether this change goes in or not. But if this patch gets committed, then eventually all of those vendors and whatever others are out there will let you do this in the same way, i.e. pg_create_subscription, instead of every vendor having their own patch to the code that does what this patch does through some method that is specific to that cloud vendor. That sort of fragmentation of the ecosystem is not good for anyone, AFAICS. > The other patch you posted seems like it makes a lot of progress in > that direction, and I think that should go in first. That was one of > the items I suggested previously[2], so thank you for working on that. Perhaps you could review that work? -- Robert Haas EDB: http://www.enterprisedb.com