Re: Command Triggers

Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> - What I'd much rather have is a form of the query that is replete
> with Full Qualification, so that "create table foo (id serial primary
> key, data text not null unique default 'better replace this', dns_data
> dnsrr not null);" may be transformed into a safer form like: "create
> table public.foo (id serial primary key, data text not null unique
> default 'better replace this'::text, dns_data dns_rr.dnsrr not null);"

Andres did the same comment and I've begun working on that. The
facility for fully qualifying object names are not always available in a
form that we can use from the parsetree, but that's a SMOP.

> What's not clear, yet, is which transformations are troublesome. For
> instance, if there's already a sequence called "foo_id_seq", then the
> sequence defined for that table winds up being "foo_id_seq1", and it's
> not quite guaranteed that *that* would be identical across databases.
>
> But perhaps it's sufficient to implement what, of COMMAND TRIGGERS,
> can be done, and we'll see, as we proceed, whether or not it's enough.

I'm not convinced that having the same sequence names on the subscribers
is something we need here. Let me detail that, because maybe I just
understood a major misunderstanding in the use case I'm interested into.

I mostly use trigger based replication in cases where it's not possible
to implement failover or switchover with that technique, because I'm
doing cross-replication or more complex architectures. Failover is
handled with WAL based techniques (wal shipping, streaming rep, etc).

So I don't care that much about the sub object names (constraints,
indexes, sequences): I need them to get created on the subscriber and
that's about it. I think that's an important enough use case here.

> It's conceivable that a first implementation won't be enough to
> implement DDL triggers for Slony, and that we'd need to ask for
> additional functionality that doesn't make it in until 9.3. That
> seems better, to me, than putting it on the shelf, and having
> functionality in neither 9.2 nor 9.3...

Or maybe Slony would end up relying partly on the command trigger
facility and implementing the missing pieces in its own code base. Like
it did with the txid_snapshot data type some years ago, for example.

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