GENERATE_SERIES是PostgreSQL内置集合函数，用于生成连续整数或时间序列；基本语法为GENERATE_SERIES(start, stop, step)，step可省略默认为1，参数类型必须严格一致，否则报错。
GENERATE_SERIES 生成整数序列的基本用法
GENERATE_SERIES 是 PostgreSQL 内置的集合返回函数，直接返回一行或多行数值，常用于补全缺失日期、构造测试数据或生成连续 ID。它不依赖表，也不需要 FROM 子句（但通常配合 SELECT 使用）。
最常用形式是三参数版本：GENERATE_SERIES(start, stop, step)，其中 step 可省略，默认为 1；所有参数必须同为整数或同为时间类型，否则报错 function generate_series(integer, integer, unknown) does not exist。
-
GENERATE_SERIES(1, 5)→ 返回 1,2,3,4,5（共 5 行） -
GENERATE_SERIES(0, 10, 2)→ 返回 0,2,4,6,8,10 -
GENERATE_SERIES(5, 1, -2)→ 返回 5,3,1（注意：若 step 为正但 start > stop，结果为空集）
用 GENERATE_SERIES 生成日期序列
日期场景下必须显式指定类型，否则会因类型推导失败而报错 ERROR: function generate_series(timestamp without time zone, timestamp without time zone, unknown) is not unique。
推荐写法是给任意一个参数加类型修饰，例如用 ::TIMESTAMP 或 ::DATE：
GENERATE_SERIES('2024-01-01'::DATE, '2024-01-05'::DATE, '1 day'::INTERVAL)-
GENERATE_SERIES('2024-01-01', '2024-01-05', '1 day'::INTERVAL)—— 第一参数自动转为 DATE，但不建议依赖隐式转换 - 错误写法：
GENERATE_SERIES('2024-01-01', '2024-01-05', '1 day')——'1 day'类型不明确，PostgreSQL 无法选择对应函数签名
在 JOIN 或子查询中使用时的性能与注意事项
GENERATE_SERIES 本身很快，但若在大表上做 CROSS JOIN 或未加限制地嵌套使用，可能瞬间产生百万行，拖慢查询甚至耗尽内存。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
常见误用场景包括：用它补全某字段缺失值时未关联条件，导致笛卡尔积；或在 WHERE 中对生成列做复杂计算却没加索引提示。
- 安全做法：始终用
LIMIT测试输出行数，例如SELECT * FROM GENERATE_SERIES(1, 1000) LIMIT 10 - 关联补全时，确保 JOIN 条件明确，例如按日期左连日志表：
LEFT JOIN log ON d.day = log.event_date，其中d.day来自GENERATE_SERIES - 避免在函数内部调用
GENERATE_SERIES并返回多行——它不能直接用于普通标量上下文，会报错more than one row returned by a subquery used as an expression
替代方案与边界情况处理
当需要更灵活的序列逻辑（比如跳过周末、按业务规则递增），GENERATE_SERIES 就力不从心了。此时应考虑 RECURSIVE CTE 或应用层生成。
另外注意两个边界行为：
- 如果
start = stop且step ≠ 0，返回单行（不是空） - 如果
step = 0，会报错step size cannot be zero，哪怕只传两个参数也隐含 step=1，所以双参数调用不会触发此错 - 浮点数支持有限：仅
GENERATE_SERIES(float8, float8, float8)存在，但精度误差常见，不建议用于金融或唯一键生成
真正麻烦的不是语法，而是忘记类型对齐和范围控制——多数线上问题都出在这两处。
