On Mon, 9 Oct 2023 at 12:18, Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Mon, Oct 9, 2023 at 3:32 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Oct 6, 2023 at 12:15 PM Peter Smith <smithpb2250@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
