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