On 10/11/14 23:37, Christopher Browne wrote:
> On 8 November 2014 17:49, Robert Haas <robertmhaas@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
