> Christopher Browne wrote:
>> A thought, open for debate...
>>
>> The node numbers are visible, and a bit painful to work with, in that
>> they are inherently a bit "numerically cryptic."
>>
>> It would seem an attractive idea to extend nodes to have a node name.
>> Thus, we might extend sl_node thus:
>
> Would it be more straightforward to just change the node ID from being
> an integer to being a varchar?  In concept at least, not sure about the
> effort required.

I don't think that would be nearly as straightforward; it would require
wholesale changes throughout the entire codebase.

Adding a field to sl_node would localize changes pretty much to slonik;
stored procedures and slon would remain virtually unchanged.  It would be
nice to have slon use the names in logs, but the existence of the names
would be transparent to everything other than slonik.

Furthermore, NOT having the name be separate from the ID eliminates one of
the would-be merits of this indirection, namely that it introduces the
ability to rename nodes.

- If the node name is an attribute of the node, it's no big deal to rename
it.  That is one update on one table.  It needs to be broadcast to the
other nodes; still no big deal.

- If, however, the name becomes the new primary key, it becomes impossible
to ever change that value, because there are only three Slony-I tables
that _don't_ have references to the node ID, namely sl_table, sl_sequence,
and sl_trigger.  Renaming a node would require locking ALL entries in ALL
tables on ALL Slony-I nodes save those three during the duration of the
renaming operation.