aliasing2

common/proto/table_definition.proto

@@ -108,14 +108,18 @@ message PostTableDefinitionRequest {
 // column, though, so it is free to be anything: this is where that choice is
 // made, instead of a RenameColumnAlias call afterwards.
 //
-// The ACCOUNTING_TRANSFER connectors are the exception. They are refused here
-// exactly as RenameColumnAlias refuses them.
+// Only ACCOUNTING's columns may be renamed. Renaming a generated column
+// requires its relationship to whatever generated it to be recorded, so the
+// rest of the system can find it without knowing its name; ACCOUNTING has that
+// in table_accounting_definitions, and nothing else does. The ACCOUNTING_
+// TRANSFER connectors and the PHONE and IBAN companions are refused, the
+// latter because a row write finds them by rebuilding their names from their
+// parent column's name.
 message GeneratedColumnAlias {
   // The name the backend would otherwise give the column: one of ACCOUNTING's
-  // "name", "tax_point_date", "debit", "credit" or "account", or a companion
-  // such as "work_phone_extension". Must name a column the request really
-  // generates -- an alias for anything else is rejected rather than ignored,
-  // so a typo cannot pass silently.
+  // "name", "tax_point_date", "debit", "credit" or "account". Must name a
+  // column the request really generates -- an alias for anything else is
+  // rejected rather than ignored, so a typo cannot pass silently.
   string generated_name = 1;
 
   // What the column should be called instead. Same rules as any column name.