Re: Command Triggers

On Tue, Dec 13, 2011 at 9:59 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Now, all that having been said, I also agree that the perfect can be
> the enemy of the good, and we go there frequently.  The question I'm
> asking is not whether the feature is perfect, but whether it's
> adequate for even the most basic things people might want to do with
> it.  Dimitri says that he wants it so that we can add support for
> CREATE TABLE, ALTER TABLE, and DROP TABLE to Slony, Bucardo, and
> Londiste.  My fear is that it won't turn out to be adequate to that
> task, because there won't actually be enough information in the CREATE
> TABLE statement to do the same thing on all servers.  In particular,
> you won't have the index or constraint names, and you might not have
> the schema or tablespace information either.  But maybe we ought to
> put the question to the intended audience for the feature - is there a
> Slony developer in the house?

Yeah, I'm not certain yet what is being provided, and the
correspondence with what would be needed.

- It's probably not sufficient to capture the raw statement, as that
gets invoked within a context replete with GUC values, and you may
need to duplicate that context/environment on a replica. Mind you, a
command trigger is doubtless capable of querying GUCs to duplicate
relevant portions of the environment.

- 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);"

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.

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...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"