OK, so this is leading us to the following points: - Use a JSON object to define the quorum/priority groups for the sync state. - Store it as a GUC, and use the check hook to validate its format, which is what we have now with s_s_names - Rely on SIGHUP to maintain an in-memory image of the quorum/priority sync state - Have the possibility to define group labels in this JSON blob, and be able to use those labels in a quorum or priority sync definition.
+1
- For backward-compatibility, use for example s_s_names = 'json' to switch to the new system.
Seems easy enough to check to see if it is has a leading { and then treat it as if it is an attempt to use JSON (which may fail), otherwise use the old syntax.
Also, as a first step of the implementation, do we actually need a set of functions to manipulate the JSON blob. I mean, we could perhaps have them in contrib/ but they do not seem mandatory as long as we document correctly how to document a label group and define a quorum or priority group, no?
Agreed, no specific functions needed to manipulate this field.
If we lack the means to manipulate JSON in SQL that can be solved outside of the scope of this patch, because its just JSON.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
