On Wed, Apr 13, 2016 at 4:38 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > Anyway, who agrees with the overall design of pglogical and who does not?
I haven't spent very much time on it yet. I tend to prefer the idea of integrating it more deeply into core and adding SQL syntax around it, but I'm not going to fight tooth and nail for that if a contrary consensus emerges.
1) "more deeply into core"
I'm open to doing that for some parts of the code, if there is benefit. At present, an extension has exactly the same attributes as an in-core solution, so I don't currently see any benefit in doing so. Could you explain what you see?
2) "SQL syntax"
I'm not sure what SQL syntax would give us. I know what we would lose, which is the ability to implement new and interesting features as extensions before putting them into core. That doesn't strike me as a benefit, so please explain.
At present, I don't understand why we would do sharding via FDWs, i.e. an out-of-core solution and yet replication as an in-core solution. Sharding desires/requires a single system image, so tight coupling is sensible (for example, defining a distribution key column on a distributed table). For replication between disparate loosely coupled systems, tight coupling is exactly what you do not want. So doing it that way round would give an an out-of-core solution for something that is best done in-core and an in-core solution for something best done out-of-core.
I think this would be a good topic to discuss at PGCon.
I'll be at PgCon to discuss this.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
