On Tue, Nov 17, 2015 at 7:52 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > Oops. > > At Tue, 17 Nov 2015 19:40:10 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote in > <20151117.194010.17198448.horiguchi.kyot...@lab.ntt.co.jp> >> Hello, >> >> At Tue, 17 Nov 2015 18:13:11 +0900, Masahiko Sawada <sawada.m...@gmail.com> >> wrote in <CAD21AoC=an+dkynwsjp6coz-6qmhxxuenxvpisxgpxcuxmp...@mail.gmail.com> >> > >> One question is that what is different between the leading "n" in >> > >> s_s_names and the leading "n" of "n-priority"? >> > > >> > > Ah. Sorry for the ambiguous description. 'n' in s_s_names >> > > representing an arbitrary integer number and that in "n-priority" >> > > is literally an "n", meaning "a format with any number of >> > > priority hosts" as a whole. As an instance, >> > > >> > > synchronous_replication_method = "n-priority" >> > > synchronous_standby_names = "2, mercury, venus, earth, mars, jupiter" >> > > >> > > I added "n-" of "n-priority" to distinguish with "1-priority" so >> > > if we won't provide "1-priority" for backward compatibility, >> > > "priority" would be enough to represent the type. >> > > >> > > By the way, s_r_method is not essentially necessary but it would >> > > be important to avoid complexity of autodetection of formats >> > > including currently undefined ones. >> > >> > Than you for your explanation, I understood that. >> > >> > It means that the format of s_s_names will be changed, which would be not >> > good. >> >> I believe that the format of definition of "replication set"(?) >> is not fixed and it would be more complex format to support >> nested definition. This should be in very different format from >> the current simple list of names. This is a selection among three >> or possiblly more disigns in order to be tolerable for future >> changes, I suppose. >> >> 1. Additional formats of definition in future will be stored in >> elsewhere of s_s_names. >> >> 2. Additional format will be stored in s_s_names, the format will >> be automatically detected. >> >> 3. (ditto), the format is designated by s_r_method. >> >> 4. Any other way? >> >> I choosed the third way. What do you think about future expansion >> of the format? >>
I agree with #3 way and the s_s_name format you suggested. I think that It's extensible and is tolerable for future changes. I'm going to implement the patch based on this idea if other hackers agree with this design. Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
