aliasing3

common/proto/table_definition.proto

@@ -108,18 +108,17 @@ message PostTableDefinitionRequest {
 // column, though, so it is free to be anything: this is where that choice is
 // made, instead of a RenameColumnAlias call afterwards.
 //
-// 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.
+// ACCOUNTING, PHONE and IBAN generated columns may be renamed: their
+// relationships are recorded by physical column, so the rest of the system can
+// find them without knowing their display names. ACCOUNTING_TRANSFER connectors
+// are the exception and are refused here exactly as RenameColumnAlias refuses
+// them.
 message GeneratedColumnAlias {
   // The name the backend would otherwise give the column: one of ACCOUNTING's
-  // "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.
+  // "name", "tax_point_date", "debit", "credit" or "account", or a PHONE or
+  // IBAN companion such as "work_phone_ext". 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.

common/src/proto/komp_ac.table_definition.rs

@@ -56,20 +56,19 @@ pub struct PostTableDefinitionRequest {
 /// column, though, so it is free to be anything: this is where that choice is
 /// made, instead of a RenameColumnAlias call afterwards.
 ///
-/// 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.
+/// ACCOUNTING, PHONE and IBAN generated columns may be renamed: their
+/// relationships are recorded by physical column, so the rest of the system can
+/// find them without knowing their display names. ACCOUNTING_TRANSFER connectors
+/// are the exception and are refused here exactly as RenameColumnAlias refuses
+/// them.
 #[derive(serde::Serialize, serde::Deserialize)]
 #[derive(Clone, PartialEq, Eq, Hash, ::prost::Message)]
 pub struct GeneratedColumnAlias {
     /// The name the backend would otherwise give the column: one of ACCOUNTING's
-    /// "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.
+    /// "name", "tax_point_date", "debit", "credit" or "account", or a PHONE or
+    /// IBAN companion such as "work_phone_ext". Must name a column the request
+    /// really generates -- an alias for anything else is rejected rather than
+    /// ignored, so a typo cannot pass silently.
     #[prost(string, tag = "1")]
     pub generated_name: ::prost::alloc::string::String,
     /// What the column should be called instead. Same rules as any column name.