Hi,
alfranio correia junior wrote:
> We have the following commands:
>
> SET TRANSACTION MASTER
>
> and
>
> CREATE TRIGGER <name> for { STARTUP | SHUTDOWN |
> BEGIN TRANSACTION | COMMIT TRANSACTION | ROLLBACK TRANSACTION }
> execute procedure <func> ( <funcargs> )
Okay.
> I think that we should discuss requirements first instead of going
> towards syntax. The latter is the last step to achieve a common
> set of ideas.
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.
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).
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 agree that it's helpful to modularize it in code. But you don't need
hooks for that.
I know I'm probably somewhat alone with that point of view.
Regards
Markus