STRING_AGG不支持text/ntext/xml类型输入，须显式转换为NVARCHAR(MAX)或VARCHAR(MAX)；PostgreSQL中TEXT可直用但需注意类型显式转换、内存限制及排序开销。
STRING_AGG 不支持 CLOB 类型输入（SQL Server）
SQL Server 的 STRING_AGG 明确拒绝 text、ntext 和 xml 类型作为第一参数，报错信息是：Argument data type text is invalid for argument 1 of string_agg function。CLOB 在 SQL Server 中对应的是 text（已弃用）或 varchar(max)/nvarchar(max)，但若列定义为 text，哪怕内容很短，也会直接被拦在函数入口外。
- 必须显式转换：
STRING_AGG(CAST(clob_col AS NVARCHAR(MAX)), ', ')或STRING_AGG(CONVERT(NVARCHAR(MAX), clob_col), ', ') - 不推荐用
CONVERT(VARCHAR, clob_col)—— 缺少长度声明会默认截成VARCHAR(30)，导致严重数据丢失 -
ntext同理，必须先转NVARCHAR(MAX)，不能只用CAST(... AS VARCHAR)，否则可能乱码
PostgreSQL 中的 “CLOB” 实际是 TEXT，但仍有隐式限制
PostgreSQL 没有 CLOB 类型，等价的是 TEXT。它允许 STRING_AGG(text_col, ', ') 直接使用，但有两个易忽略的约束：
- 若
text_col表达式中混入了非文本类型（如bytea、jsonb），必须显式转：STRING_AGG(col::TEXT, ', ')，否则报function string_agg(bytea, unknown) does not exist - 当拼接结果总长预估超 1GB 时，PostgreSQL 可能静默截断或抛出
out of memory错误——这不是STRING_AGG本身限制，而是 backend 内存配置和 work_mem 设置所致 - 别依赖自动类型提升：写
STRING_AGG(id, ', ')（id 是INT）会失败，必须写STRING_AGG(id::TEXT, ', ')
跨数据库“CLOB 拼接”的真正瓶颈不在函数，而在排序与内存
即使类型转换搞定，大 CLOB 字段拼接仍大概率慢或失败，原因不是 STRING_AGG 本身，而是它背后的行为：
-
WITHIN GROUP (ORDER BY ...)要求对每个待拼接值做完整排序，若字段平均长度 10KB、分组内有 1 万行，仅排序阶段就需约 100MB 内存；SQL Server 容易触发 TempDB spill，PostgreSQL 可能耗尽work_mem - 空值处理若用
CASE WHEN clob_col IS NULL THEN '' ELSE clob_col END，会导致所有非 NULL 值被强制转成字符串再拼接，放大内存压力；更安全的是CASE WHEN clob_col IS NULL THEN NULL ELSE clob_col END（让 NULL 被跳过） - 如果只是想“取前 N 个非空值拼起来”，别硬扛全量聚合——先用
ROW_NUMBER() OVER ()在子查询里限流，再对外层结果STRING_AGG
替代方案比强行转类型更实际
当 CLOB 字段真实存在且体积大，STRING_AGG 往往不是最优解：
- SQL Server：老式
FOR XML PATH('')在某些场景下内存更友好，尤其无排序需求时 - PostgreSQL：若只需去重拼接，
STRING_AGG(DISTINCT clob_col::TEXT, ', ')可能比先DISTINCT ON再聚合更简洁，但注意DISTINCT会额外消耗哈希内存 - 真正的大文本拼接（如日志归并），应考虑把逻辑移到应用层——数据库擅长结构化聚合，不擅长搬运和缝合大块非结构化文本
STRING_AGG 的输入流，它就不再是“字段值”，而成了“待缓冲、待排序、待拼接的内存块”。控制不住单条记录大小，就控制不住整个聚合的稳定性。 
