On Thu, Feb 4, 2016 at 2:49 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> Yes, please let's use the custom language, and let's not care of not >>> more than 1 level of nesting so as it is possible to represent >>> pg_stat_replication in a simple way for the user. >> >> "not" is used twice in this sentence in a way that renders me not able >> to be sure that I'm not understanding it not properly. > > 4 times here. Score beaten. > > Sorry. Perhaps I am tired... I was just wondering if it would be fine > to only support configurations up to one level of nested objects, like > that: > 2[node1, node2, node3] > node1, 2[node2, node3], node3 > In short, we could restrict things so as we cannot define a group of > nodes within an existing group.
I see. Such a restriction doesn't seem likely to me to prevent people from doing anything actually useful. But I don't know that it buys very much either. It's often not very much simpler to handle 2 levels than n levels. However, I ain't writing the code so... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
