>> > 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.
Not sure. In some places I think "option" is an abbreviation of "optional parameter". So using "option" there does not seem to be inconsistent or incorrect. See following example in create subscription manual: This clause specifies optional parameters for a subscription. : : connect (boolean) : : Since no connection is made when this option is false, no tables are subscribed. > Also, the "public" parameter in CREATE PUBLICATION doc, You mean "publish"? > "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. I would like to hear opinions from native English speakers. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
