On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote: > You must choose a single role you want the subscription to run > under.
I think that was the source of a lot of my confusion: Your patches are creating the notion of a "run as" user by assigning ownership-that-isn't-really-ownership. I got distracted wondering why you would really care if some user could enable/disable/refresh/rename a subscription, but the main point was to change who the subscription runs as. That's a more general idea: I could see how "run as" could apply to subscriptions as well as functions (right now it can only run as the owner or the invoker, not an arbitrary role). And I better understand your analogy to security definer now. But it's also not exactly a simple idea, and I think the current patches oversimplify it and conflate it with ownership. > I think the longer term plan is that non-superusers who have some > privileged role will be allowed to create subscriptions, You earlier listed some challenges with that: https://postgr.es/m/cf56ac0d-7495-4e8d-a48f-ff38bd807...@enterprisedb.com But it seems like it's really the right direction to go. Probably the biggest concern is connection strings that read server files, but dblink solved that by requiring password auth. What are the reasonable steps to get there? Do you think anything is doable for v15? > There is a cart-before-the-horse problem here. I don't think we need to hold up v2-0003. It seems like a step in the right direction, though I haven't looked closely yet. Regards, Jeff Davis
