It's a good project I wrote years ago. It implements Java-like reflection in C++. Just declare your reflection, and use it via Java-like API. Annotation and object proxy just like Java is also supported.

See https://github.com/kingluo/boost-reflection/tree/master/libs... for examples.

Reflection is the base to implement framework like Java Spring, see https://github.com/kingluo/boost-reflection/tree/master/libs..., which is a simple IOC example.

Note that LWW is optional, pgcat implement LWW in trigger way, see the pgcat_setup_lww (https://github.com/kingluo/pgcat/tree/master/cmd/pgcat_setup...).

Yes, if multi-masters change the same rows of same table, it would cause conflict.

Consensus protocol like raft, has limitation: it requires low delay among the nodes, so normally, it would be deployed in the same data-center. Moreover, if all changes (conflict or not), handled by consensus protocol, the performance would be bad. In fact, data-centers are normally loose coupling (the application normally choose the same data-center as the data source/target). So data-centers just need somehow light-weighted conflict resolution.

pgcat lww, just like Cassandra, provides counter column concept, which is used to retain each change among data-centers, and simple aggregation helper function there. pgcat lww is done by pg trigger, so if you need customization of your business, you could modify the trigger function to fit it.

Yes, the template generated sql would bring some overhead. But it's the cost for flexibility: The target table would not be limited to base table. It could be a view, a foreign table, partitioned table, or citus distributed table. And, it also support table name mapping.

You can detect whether a target is a plain table or not. And use a different path if not.

And independent of using SQL or not: Executing them separately out of process kills you via latency, even if you're on the same machine. The context switches are just too expensive. Which makes single threaded apply untenable for anything with a few more clients, or bulk load.

I would try to do more test for performance, especially in product environment.

Detect the target table is easy, but it seems tricky to redirect the flow to pg build-in logical replication (not necessary to re-implement it, especially it was written in C language, so redirection is the right way).

In fact, you could use pg logical replication directly for some cases like big and real-time data flows. But currently, it has one big flaw: bi-directional replication or multi-master replication is impossible, where it would cause dead cycle loops, because it do not filter any origin currently, you could check function pgoutput_origin_filter.

And, even if the filter is right, it still lacks of conflict solution, but pgcat could help there, and you don't need to use pgcat, because pgcat has trigger way to resolve conflict, you could check pgcat_setup_lww command.