Hi !!!
> I still maintain the point that I want to check requirements first. For
> that I need a working prototype. And I'm easy with prototyping in C in
> the backend code. If there's really a requirement for hooks, I can add
> them and decouple from PostgreSQL source code later on.
I agree with you. You should build prototypes and try things in order to
figure out exactly what we need.
However, based on the experience that you already have in developing
such prototypes most likely there are different futures that would like
to see into PostgreSQL. What are they ?
> What do you currently base your hooks on? IMO it's just naive to expect
> to be able to define hooks now, especially hooks as general as you seem
> to be heading to (I've read about sync and async multi master
> replication, single master replication as well as materialized views).
You have "prototypes" built upon such hooks: sync and async, single
master and multi master. However, I am not arguing that hooks are the
solution to any problem. But they work for the limited view that we have
on the subject.
> Another point: modularization is nice and well, where appropriate. But
> here I don't see how it could help the user. Or do you expect users to
> plug in and out replication solutions like USB sticks? I think most
> users want to have *one* replication solution that works. Out of the
> box. Maybe they want one which can do sync as well as async replication,
> sure. But hooks don't give you that, nor do they make it any easier.
I don't expect that. But I would like to test different replication
protocols without patching the PostgreSQL. And I believe that we might
come up with a set of in-core features that would enable this.
Regards,
Alfranio.