Re: Enhance create subscription reference manual

>> > 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