><programlisting> >CREATE PUBLICATION mypub; >ALTER PUBLICATION mypub ADD TABLE users, departments;
>CREATE SUBSCRIPTION mysub WITH CONNECTION <quote>dbname=foo host=bar >user=repuser</quote> PUBLICATION mypub; > The above will start the replication process which synchronizes the > initial table contents of <literal>users</literal> and > <literal>departments</literal> tables and then starts replicating > incremental changes to those tables. Hi, hackers. it is very good to have logical replication in core. Also i have some proposal. What if we would have ability to execute custom trigger functions on events on particular table? Also it would be useful if would have ability to ignore some tables in publication or replicatie with some WHERE condition. For example, we want replicate table "users" as is (maybe with some WHERE conditions), but on events on table "departments" we want execute trigger function departments_event_handler(). And we don't want handle events on third table which was added to publication. Something like this: CREATE PUBLICATION mypub; ALTER PUBLICATION mypub ADD TABLE users, departments, unnecessary_tbl; CREATE SUBSCRIPTION mysub WITH CONNECTION <quote>dbname=foo host=bar user=repuser</quote> PUBLICATION mypub; ALTER SUBSCRIPTION mysub ADD TABLE users REPLICATE TO LOCAL TABLE my_users INSERT WHERE new.id_user > 1000 UPDATE WHERE old.id_user < 1000; -- we don't want replicate deletes, for example. ALTER SUBSCRIPTION mysub ADD TABLE departments ON INSERT WHEN (new.id_user > 1000) EXECUTE PROCEDURE departments_event_handler(); -- just like trigger Regards, Dmitriy Sarafannikov -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
