On 10/11/14 23:37, Christopher Browne wrote:
On 8 November 2014 17:49, Robert Haas <robertmh...@gmail.com > > My impression, based on something Christopher Brown said a few years > ago, is that Slony's DDL trigger needs are largely satisfied by the > existing event trigger stuff. It would be helpful to get confirmation > as to whether that's the case.I'm not sure that a replication system that intends to do partial replication (e.g. - being selective of what objects are to be replicated) will necessarily want to use the CREATE event triggers to capture creates. Several cases pop up with different answers: a) I certainly don't want to replicate temporary tables b) I almost certainly don't want to replicate unlogged tables c) For "more ordinary" tables, I'm not sure I want to extend Slony to detect them and add them automatically, because there are annoying sub-cases c.1) If I'm working on data conversion, I may create not totally temporary tables that are nonetheless not worthy to replicate. (I'm working on such right now) Long and short: it seems likely that I'd frequently NOT want all new tables added to replication, at least not all of them, all the time.
I don't see how this is problem with using CREATE event triggers, just put logic in your trigger that handles this, you get the object identity of the object that is being created/altered so you can get any info about it you wish and you can easily filter however you want.
There are kind of two approaches: a) Just capture the OIDs, and have replication go back later and grab the table definition once the dust clears on the master b) We need to capture ALL the DDL, whether CREATE or ALTER, and forward it, altered to have fully qualified names on everything so that we don't need to duplicate all the "set search_path" requests and such.
This is basically what this patch gives you (actually both the canonized command and the identity)?
I suppose there's also a third... c) Have a capability to put an event trigger function in place that makes DDL requests fail. That's more useful than you'd think; if, by default, we make them fail, and with an error messages such as "DDL request failed as it was not submitted using slonik DDL TOOL"
You can do that already, it's even the example in the event trigger documentation.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
