On Mon, 9 Oct 2023 at 12:18, Peter Smith <smithpb2...@gmail.com> wrote: > > On Mon, Oct 9, 2023 at 3:32 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Oct 6, 2023 at 12:15 PM Peter Smith <smithpb2...@gmail.com> wrote: > > > > > > Here is a patch to add the 2 missing references: > > > > > > ref/alter_subscription.sgml ==> added more ids > > > ref/alter_publication.sgml ==> added link to > > > "sql-altersubscription-refresh-publication" > > > ref/drop_subscription.sgml ==> added link to "sql-altersubscription" > > > > > > > - <varlistentry> > > + <varlistentry id="sql-altersubscription-new-owner"> > > <term><replaceable class="parameter">new_owner</replaceable></term> > > <listitem> > > <para> > > @@ -281,7 +281,7 @@ ALTER SUBSCRIPTION <replaceable > > class="parameter">name</replaceable> RENAME TO < > > </listitem> > > </varlistentry> > > > > - <varlistentry> > > + <varlistentry id="sql-altersubscription-new-name"> > > <term><replaceable class="parameter">new_name</replaceable></term> > > <listitem> > > > > Thanks for looking at this patch! > > > Shall we append 'params' in the above and other id's in the patch. For > > example, sql-altersubscription-params-new-name. The other places like > > alter_role.sgml and alter_table.sgml uses similar id's. Is there a > > reason to be different here? > > In v1, I used the same pattern as on the CREATE SUBSCRIPTION page, > which doesn't look like those... > > ~~~ > > The "Parameters" section describes some things that really are parameters: > > e.g. > "sql-altersubscription-name" > "sql-altersubscription-new-owner" > "sql-altersubscription-new-name"> > > I agree, emphasising that those ones are parameters is better. Changed > like this in v2. > > "sql-altersubscription-params-name" > "sql-altersubscription-params-new-owner" > "sql-altersubscription-params-new-name"> > > ~ > > But, the "Parameters" section also describes other SQL syntax clauses > which are not really parameters at all. > > e.g. > "sql-altersubscription-refresh-publication" > "sql-altersubscription-enable" > "sql-altersubscription-disable" > > So I felt those ones are more intuitive left as they are -- e.g., > instead of having ids/linkends like: > > "sql-altersubscription-params-refresh-publication" > "sql-altersubscription-params-enable" > "sql-altersubscription-params-disable" > > ~~ > > PSA v2.
I noticed a couple of other places where a link to "ALTER SUBSCRIPTION ... DISABLE" and "ALTER SUBSCRIPTION ... SET" can be specified in drop_subscription: To proceed in this situation, first disable the subscription by executing <literal>ALTER SUBSCRIPTION ... DISABLE</literal>, and then disassociate it from the replication slot by executing <literal>ALTER SUBSCRIPTION ... SET (slot_name = NONE)</literal>. Regards, Vignesh
