kdb+中不同表连接方式对枚举列处理差异原因问询

kdb+不同连接操作枚举处理差异的底层原因 #

核心差异来自三类操作的类型处理逻辑不同：

• (,/) 采用底层向量拼接逻辑，无自动类型兼容转换
  (,/)本质是对输入的表列表执行基础二元,操作的左累加。基础的,做向量拼接时遵循左类型优先、最小改动原则：只会尝试将右操作数的向量转换为左操作数的类型，转换失败时直接返回混合类型列表，不会主动做类型降级。
  枚举是绑定了域名的符号子类型，基础,不会主动将枚举反转为普通符号，当左表列是枚举类型、右表列是普通符号时，无法把普通符号隐式转为枚举类型（kdb不允许无显式声明的普通符号转枚举），因此最终得到枚举值和普通符号混合的列。
  可以通过调换表顺序验证该逻辑：当左表列是普通符号时，右表的枚举可以隐式转为普通符号，(,/)也会得到统一的符号列：

  q)(,/) (t2;t1)
  c1
  --
  a
  b
  a
  b
  

• uj/ 属于表结构级合并操作，内置类型兼容处理
  联合连接（uj）的设计目标是输出结构完全一致的合并表，内部会先对所有同名列做类型兼容性校验，自动推导两边的公共超类型后做统一转换。枚举和普通符号的公共超类型为普通符号，因此uj会自动将枚举列反枚举为普通符号，再执行合并，最终返回统一类型的列。
• last (,\) 属于累积表join操作，和uj共用类型转换逻辑
  ,\是表的累积join操作，属于结构化合并类操作，和uj共用同一套列类型兼容处理逻辑，同样会先将同名列转换为公共超类型再合并，因此也会自动完成反枚举处理。

内容的提问来源于stack exchange，提问作者Dunny