Re: Command Triggers - Mailing list pgsql-hackers

Jan Wieck <JanWieck@Yahoo.com> writes:
> I agree. While it is one of the most "asked for" features among the trigger
> based replication systems, I fear that an incomplete solution will cause
> more problems than it solves. It is far easier to tell people "DDL doesn't
> propagate automatically, do this instead ..." than to try to support a
> limited list of commands, that may or may not propagate as intended. And all

Nothing stops you from checking that the command you want to replicate
is indeed supported and refuse to run it on the provider when not,
that's what command triggers are for :)

> sorts of side effects, like search_path, user names and even the existing
> schema in the replica can cause any given DDL "string" to actually do
> something completely different than what happened on the origin.

Grab those on the provider from pg_settings and the like in the command
trigger and restore them on the subscriber before applying the command?

> On top of that, the PostgreSQL main project has a built in replication
> solution that doesn't need any of this. There is no need for anyone, but us
> trigger replication folks, to keep command triggers in sync with all other
> features.

You can't implement cross replication with built-in replication. I'm yet
to work on a medium sized project where I don't need both streaming
replication, wal archiving, and a trigger based replication system.

> I don't think it is going to be reliable enough any time soon to make this
> the default for any of the trigger based replication systems.

You need to add "yet" and "without some work in the client implementation".

Last time I read such comments, it was about extensions. We still
shipped something in 9.1, and by your measure, it's quite broken. When
you implement an SQL only extension (no .so) you still have to use a
Makefile and you need to deploy your scripts on the server filesystem
before hand, it's not possible to install or update the extension from
an SQL connection (even when doing only self-contained SQL commands).

Also, the dependency system is not solving much real world problems,
apart from the very simplest one that we can play with in contrib/.

You can't even list shared objects (.so, .dll) that have been loaded so
far in a session and reference the extension they belong to.

Yet, I bet that some people will find that the extension system as we
have it in 9.1 still is useful enough to have been released in there.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

PS: yes I intend to be working on fixing those extension limitations and   caveats with a series of patches.