大佬们，周末好😄

以下两个问题在使用集算器的过程中经常会卡住，影响编写节奏，恳请大佬们得空时看看能否改善。

一、通配符的使用

目前，集算器语法对通配符的支持出现在两个地方，directory@ps 列出文件路径和 like 匹配字符串，
但只支持非常有限的匹配模式，似乎只有 * 和?。我想着能不能扩展一下基础用法，比如，

1、字符组 [] 的用法：
[abc]: a、b、c 中的任意一个
[0-9A-Z]: - 表示范围, 匹配 0 到 9A-Z 中的任意一个
[!abc] 或者 [^abc]: 否定字符组, 不在括号内的任意一个字符

2、模式组 {} 的用法：

*.{csv,txt}: 表示匹配 *.csv 或者 *.txt

扩展原因：

1、基础通配符在查找匹配路径和文件名时很有用，虽然目前可以用.select(regex()) 用正则做后续复杂处理得到想要的结果，但如果能直接使用会少一些步骤，更加友好易用；

2、市面上大多数能用通配符引擎的都支持字符组 [] 的用法，没有其它多余的花样，实用且不臃肿。

二、合并序表时的字段对齐 (Vertical Stacking and Coulmn Mapping)

字段对齐合并在实务中属于常见典型需求，出现频率非常高。理想状态是所有表格的字段名、字段数量、字段顺序都是一致的，这种场景下只要在垂直方向上无脑堆叠就行，但实务中碰到的情况往往是五花八门的，最近处理过的一个场景就是 12 张表同样的字段属性，正常只需 32 个字段，但实际上去重合并后有 102 个字段名，其中的很多都是同样的属性取了不同的名称，换个软件工程师就换个命名，做数据分析的几乎 8 成的时间和耐心都花在这种统一字段名合并表格上，缝缝补补如同绣花。而目前市场上也没有几个像样的针对字段对齐的友好易用的方法，了解到的有：

1、pandas 在大约 15 年前设计了 concat 函数，可以把不同数据结构的几个 dataframe 在合并时实现所有的字段对齐。

2、PySpark 在 2018 年添加了 unionByName 功能，并在 2021 年 3 月增加了处理新列添加的功能；

3、2022 年左右 DuckDB 数据库设计了 union_by_name 用于获取外部多个文件并实现字段对齐的垂直堆叠。
read_csv([‘*.csv’],union_by_name=true)；
read_sheets([‘*.xlsx’],sheets=[‘*’],union_by_name=true)

似乎目前市面上也只有这 3 种方法能实现简单易用的 Vertical Stacking and Column Mapping，其它的只能通过写超长的代码来实现。

集算器在处理字段对齐时有 3 种方法，
insert@f
modify@f
json@t(json([ 序表 1，序表 2].conj()))

但这 3 种方法都是针对序表的，如果读取到的文件很大，要通过游标来处理时就不适用了。而且在处理序表时，堆叠后的文件行数很多，也会导致内存不够 GC。比如，以下合并 12 个具有不同字段名的 excel 表格，每一个表格大约 20 万行左右，最终结果大约是 240 万行 32 列，有点颇费周折：

因为字段很乱，没办法只能把所有有效字段都先写在 A2，然后把每一个大文件读成游标，B6 取出字段名，B7 用 align 实现字段名对齐，没有的写成 null，拼接成文本，再在 B8 用 new 重写一遍。这样就相当于把所有表的字段对齐了，没有的字段用 null 补全。A9 把所有游标 conj 再后续处理。

字段对齐堆叠在实务中是一个痛点，我想集算器能不能实现 union_by_name 这样的对齐操作，比如：

[序表 1, 序表 2,…序表 n].conj@union_by_name()
或者
[游标 1, 游标 2,…游标 n].conj@union_by_name()

字段对齐也有两种情形：

1、所有字段对齐，没有的字段用 null 补全，相当于是一个 full join；
2、公有字段对齐，没有的字段都丢弃，相当于是一个 inner join；
3、字段对齐后，整体的结果是有序好还是保持原序好

这样的话这种场景的处理就会变得很简单，程序也会更加友好易用，对多源混算无疑是极大的助力。

当然，这个操作估计开销很大，简洁易用的背后全靠大佬们的智慧和高明的算法…

恳请大佬们成全🙏 🙏 功德无量🙏 🙏