> We may have a good idea of how to define a custom language, still we > are going to need to design a clean interface at catalog level more or > less close to what is written here. If we can get a clean interface, > the custom language implemented, and TAP tests that take advantage of > this user interface to check the node/group statuses, I guess that we > would be in good shape for this patch. > > Anyway that's not a small project, and perhaps I am over-complicating > the whole thing.
Yes. The more I look at this, the worse the idea of custom syntax looks. Yes, I realize there are drawbacks to using JSON, but this is worse. Further, there's a lot of horse-cart inversion here. This proposal involves letting the syntax for sync_list configuration determine the feature set for N-sync. That's backwards; we should decide the total list of features we want to support, and then adopt a syntax which will make it possible to have them. -- Josh Berkus Red Hat OSAS (opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
