A Problem Observed:

 If there are a significant number of Slony-I clusters being managed,
 which have the potential to move around (e.g. - if server names
 change, or are repurposed), it is pretty easy for the node
 "numbering" to get pretty confusing.

 One approach would be to have "node 1" be the first one set up, 2
 being the second, and so forth.

 Furthermore, there is no way to renumber things after the fact.  If
 the "logical name" of a node changes, there is still no way to change
 what amounts to a "physical" node number.

A Possible Solution

 We could add, to sl_node, a field called "no_name," which would be a
 unique field containing a string to represent the name of the node.

 This would not interrupt any of the existing usages of node numbers;
 it would mean that Slonik scripts should be able to be written to
 refer to "NODE NAME" instead of a "node number."

 Assignment of names to nodes would involve a new slonik event,
 NAME_NODE, which has two parameters, the ID number, and the new name,
 and which 'broadcasts' this name out everywhere.

 The "options," in slonik, would be extended to allow various options
 that presently specify node IDs to add "name" to them.  To wit, we
 presently have the following options that refer to nodes by ID
 number, option_item_id:

 backup node 
 event node 
 server 
 client 
 origin 
 old origin 
 new origin 
 new set 
 receiver 
 provider 
 set 
 add 
 node
 execute only on 

 They would be augmented by rules for options that are assigned
 option_item_literal values:

 backup node name
 event node name
 server name
 client name
 origin name
 old origin name
 new origin name
 new set name
 receiver name
 provider name
 set name
 add name
 node name
 execute only on node name

A Set of Affected Commands

 The following Slonik commands would need to be augmented to support
 these options (I'm ignoring the existing options that could continue
 to exist):

 init cluster (node name = 'whatever');
 store node (node name = 'whatever');
 drop node (node name='something');
 uninstall node (node name='something');
 restart node ??? Unaffected ???
 store path (server name = '', client name = '');
 drop path (server name = '', client name = '');
 store listen (origin name = '', provider name = '', receiver name = '');
 drop listen (origin name = '', provider name = '', receiver name = '');
 table add key (node name = '');
 create set (origin name = '');
 drop set (origin name = '');
 merge set (origin name = '');
 set add table (origin name = '');
 set add sequence (origin name = '');
 set drop table (origin name = '');
 set drop sequence (origin name = '');
 set move table (origin name = '');
 set move sequence (origin name = '');
 store trigger (event node name = '');
 drop trigger (event node name = '');
 subscribe set (provider name = '', receiver name = '');
 unsubscribe set (receiver name = '');
 lock set (origin name = '');
 unlock set (origin name = '');
 move set (old origin name = '', new origin name = '');
 failover (node name = '', backup node name = '');
 execute script (event node name = '', execute only on node name '');

A Scope for the Changes

 This has a quite small effect on slon, as all that this requires
 there is the addition of the new event, and a couple of stored
 procedures.

 The impact on slonik, however, is rather large, adding 14 new
 options, as well as 28 commands that potentially have to head to the
 DB to query the node ID corresponding to the name that they might be
 passed.

 It shouldn't change 'til 1.1, because, aside from the massive changes
 to slonik, it has a small but marked change to the Slony-I database
 schema, adding a field to sl_nodes.

A Set of Risks

 There are 28 commands that are affected, that have to be changed,
 tested, and documented.

 There is the possibility that some user might specify both the node
 name and the node ID (this doesn't remove the existing ID support).
 It's probably appropriate to error out in such cases, but this
 certainly introduces a new failure mode.

 Another new failure mode is that it is possible that node name
 assignment might not have propagated everywhere by the time that a
 slonik script wants to reference the name.

Comments are welcome...  I have put some of the changes into a
"scratch" copy of CVS HEAD, so that I can happily either proceed or
drop this without injuring other efforts.
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)