Can you explain why the procedure that allows you to
run (node dependent) DDL within slonik does not meet
your needs?

--elein

On Mon, Oct 18, 2004 at 04:28:55PM -0400, Christopher Browne wrote:
> We have noticed a need to run some things in a node-dependent manner,
> that is, where there are processes (triggers, to be exact) that need
> to run on some nodes, and not on other nodes.
> 
> In looking at solutions, I'm seeing that this is not something that is
> unique to just one trigger, and it looks, therefore, as though this is
> something that may be of wider interest.  There's little sense in
> hacking something up for our internal purposes if it can be added in
> for everyone else to use (and debug! :^)).
> 
> The thought:
> 
>  - Create a new table that is replicated everywhere 
> 
>    (Initial assumption: Use Slony-I to replicate it; if this
>    ultimately integrates into Slony-I, then presumably it would be
>    handled inside Slony-I...)
> 
>    create table public.sl_run_on_node (
>      service character varying(16),
>      sl_node integer,
>      primary key(service, sl_node)
>    );
> 
>  - Create a 'control function.'
> 
>    create or replace function public.run_service_here (character varying(16))
>    returns boolean as
>    'select exists (select * from public.sl_run_on_node 
>                    where service = $1
>                    and sl_node = @NAMESPACE at .getLocalNodeId(''@NAMESPACE@));'
>    language sql;
> 
> If we want a trigger that we identify as 'FOO_ON_SLAVES' to run on
> nodes 2, 4, and 6, then we'd add in the rules:
> 
> insert into sl_run_on_node (service, sl_node) values ('FOO_ON_SLAVES', 2);
> insert into sl_run_on_node (service, sl_node) values ('FOO_ON_SLAVES', 4);
> insert into sl_run_on_node (service, sl_node) values ('FOO_ON_SLAVES', 6);
> 
> The trigger would invoke a stored function, which would have to add
> in, near the beginning, the code:
> 
>    if not run_service_here('FOO_ON_SLAVES') then
>       return NEW;
>    end if;
> 
> Some questions that fall from this:
> 
>  - Does this sound like it would be generally useful?
> 
>  - Are there some manifest failings that should be fixed up?
> 
>  - How would it make sense to integrate this into Slony-I?
> 
>    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.
> -- 
> "cbbrowne","@","ca.afilias.info"
> <http://dev6.int.libertyrms.com/>
> Christopher Browne
> (416) 673-4124 (land)
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general