On 13 April 2016 at 17:48, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 4:38 AM, Simon Riggs <si...@2ndquadrant.com>
> > 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