On Tue, 2023-09-26 at 18:21 +0200, Benoit Lobréau wrote: > On 9/26/23 16:27, Benoit Lobréau wrote: > > I will try to come up with a documentation patch. > > This is my attempt at a documentation patch. >
+ If the ownership of a subscription with <literal>password_required=true</literal> + is transferred to a non-superuser, they will gain full control over the subscription + but will not be able to modify it's connection string. I think you mean false, right? + If the ownership of a subscription with <literal>password_required=true</literal> + has been transferred to a non-superuser, it must be reverted to a superuser for + the DROP operation to succeed. That's only needed if the superuser transfers a subscription with password_required=true to a non-superuser and the connection string does not contain a password. In that case, the subscription is already in a failing state, not just for DROP. Ideally we'd have some other warning in the docs not to do that -- maybe in CREATE and ALTER. Also, if the subscription is in that kind of failing state, there are other ways to get out of it as well, like disabling it and setting connection=none, then dropping it. The whole thing is fairly delicate. As soon as you work slightly outside of the intended use, password_required starts causing unexpected things to happen. As I said earlier, I think the best thing to do is to just have a section that describes when to use password_required, what specific things you should do to satisfy that case, and what caveats you should avoid. Something like: "If you want to have a subscription using a connection string without a password managed by a non-superuser, then: [ insert SQL steps here ]. Warning: if the connection string doesn't contain a password, make sure to set password_required=false before transferring ownership, otherwise it will start failing." Documenting the behavior is good, too, but I find the behavior difficult to document, so examples will help. Regards, Jeff Davis