I've had to add some "new stuff" to the "altperl" scripts to cope with
the fact that "SET ADD TABLE" isn't 'smart' enough to detect candidate
primary keys.  If you haven't got an actual PRIMARY KEY on a table,
you have to specify which candidate is to be used.

That leads to a little bit of additional complexity, and a new data
structure :-(.

The environment needs an extra table; what we had was

 @KEYEDTABLES = ("this_table", "that_table", "the_other_table");

It is replaced by:

 @PKEYEDTABLES = ("this_table_with_pkey", "that_table_with_pkey");

where the entries must be tables that actually have keys defined as primary keys.

In addition, for the ones with mere "candidates," we have:

 %KEYEDTABLES= (
                              table1 => "unique_not_null_index_on_table1",
                              table2 => "unique_not_null_index_on_table2",
                              table3 => "unique_not_null_index_on_table3",
                              table4 => "unique_not_null_index_on_table4");

I noticed one further "oddity;" there's logic to it, in fact, but it's
not obvious...

You can't do:

set add table (set id = 1, origin = 1, id = 27, 
                       full qualified name = 'nspace.some_table', 
                       key = 'nspace.key_on_whatever', 
                       comment = 'Table some_table in namespace nspace with a candidate primary key');

You have to do:

set add table (set id = 1, origin = 1, id = 27, 
                       full qualified name = 'nspace.some_table', 
                       key = key_on_whatever', 
                       comment = 'Table some_table in namespace nspace with a candidate primary key');

I can see the logic to it; it was just a bit of a surprise to not need
to FQ both pieces.  I have added mention of this to the Slonik
commands documentation.
-- 
output = ("cbbrowne" "@" "ca.afilias.info")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)