>
> Some questions that fall from this:
>
>  - Does this sound like it would be generally useful?

Yes. Actually I thougth that this *is* how STORE TRIGGER worked ;)

OTOH I can probably do "STORE TRIGGER (TRIGGER NAME ='runs_on_slaves')"
and then make the same trigger do different things on different slaves ;)

>  - Are there some manifest failings that should be fixed up?

Not an failing, but one should think through how this will play together
with switchover/failover.

>  - How would it make sense to integrate this into Slony-I?

Yes. One on my uses of slony is replicating different sets of tables to
multiple computers for OLAP processing and some of initial post-processing
here is best done using triggers. and these triggers do different things
on different computers.

I guess an extra parameter NODE to STORE TRIGGER which manipulates and
extra field in table sl_trigger (called sl_node ;)

The default could be still NODE = ALL, which adds the trigger for all nodes.

>    For instance, if more tightly integrated with Slony-I, this table
>    wouldn't be replicated, but would instead be updated via raising
>    Slony EVENTs.  And we'd need Slonik syntax for it.

and if integrated, the initial

   if not run_service_here('FOO_ON_SLAVES') then
      return NEW;
   end if;

is not needed as it is handled by slony. but you probably already thought
about that ;)

---------------
Hannu