From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enhance create subscription reference manual |
Date: | 2024-10-02 06:39:54 |
Message-ID: | 20241002153954.e1377536b7ddf3c5de5b1dac@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 02 Oct 2024 14:52:58 +0900 (JST)
Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
> >> Currently the manual explains create subscription's "failover"
> >> parameter as follows:
> >>
> >> <para>
> >> Since no connection is made when this option is
> >> <literal>false</literal>, no tables are subscribed. To initiate
> >> replication, you must manually create the replication slot, enable
> >> the failover if required, enable the subscription, and refresh the
> >> subscription. See
> >> <xref linkend="logical-replication-subscription-examples-deferred-slot"/>
> >> for examples.
> >> </para>
> >>
> >> While translating it into Japanese, we were little confused what "the
> >> failover" actually means because we thought it might refer to the
> >> failover operation or the failover parameter in the command. After a
> >> discussion in the translation team, we concluded that it must refer to
> >> the failover parameter. If we were correct, it would be nice to add
> >> <literal> tag to "failover" to make it clear that it refers to a
> >> failover parameter. Attached is the patch to do that.
> >
> > I agreed with adding <literal> tag to "failover" since it is done in the
> > description on "slot_name" parameter.
> >
> > How about also rewrite it to "enable the failover option" rather than simply
> > "enable the failover" to clarify that the parameter is refereed to.
> >
> > We could also use "enable the failover parameter". I think both make sense, but
> > it seems that "failover option" is preferred in the slot_name description.
>
> But a few lines above we have:
>
> <para>
> This clause specifies optional parameters for a subscription.
> </para>
>
> <para>
> The following parameters control what happens during subscription creation:
>
> So it seems "paramter" is more consistent than "option" here.
For consistency, using "parameter" seems better.
If we consider this, should we rewrite other places using "option" to use "parameter"?
For example, I can find uses of "option" in the "connect", "slot_name", and "binary"
descriptions in the CREATE SUBSCRIPTION document.
Also, the "public" parameter in CREATE PUBLICATION doc, "vacuum_index_cleanup" and
"vacuum_truncate" storage parameters in CREATE TABLE doc might be also targets to be
rewritten. I am not sure if this covers all, though.
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-10-02 06:45:11 | Re: POC, WIP: OR-clause support for indexes |
Previous Message | Fujii Masao | 2024-10-02 06:34:33 | Re: Add on_error and log_verbosity options to file_fdw |