postgresql 15中generate_series生成日期需起止参数同为date或timestamp类型，步长必须显式指定为interval（如'1 day'），隐式转换易失败；start>end且step为正时返回空集。
GENERATE_SERIES生成日期的基本用法
PostgreSQL 15 的 generate_series() 支持直接传入 DATE 或 TIMESTAMP 类型的起止值，无需手动转换单位或拼接字符串。只要两个端点类型一致且为时间类型，函数就能按天（或更小粒度）自动步进。
默认步长是 1 天；若需小时、分钟级，必须显式指定第三个参数（interval 类型）。
-
generate_series('2024-01-01'::DATE, '2024-01-05'::DATE)→ 每行一个 DATE，共 5 行（含首尾） -
generate_series('2024-01-01'::TIMESTAMP, '2024-01-02 06:00'::TIMESTAMP, '6 hours'::INTERVAL)→ 每 6 小时一行，从 00:00 到 06:00（含） - 不写类型强制转换（如
'2024-01-01'）可能触发隐式转换失败，尤其当列参与 JOIN 或 WHERE 时
常见错误：步长单位不匹配导致空结果或报错
最典型的错误是把数字当 interval 用，比如 generate_series(start_date, end_date, 1) —— PostgreSQL 会尝试把整数 1 转成 interval，但失败并抛出 ERROR: setval: value 1 is out of bounds for sequence 这类误导性错误（实际和序列无关）。
- 正确写法必须用
INTERVAL字面量：'1 day'、'7 days'、'1 hour'、'30 mins' -
'1d'不合法，'1 day'才是标准语法；'1days'也不行（复数必须带 s，但前面要空格） - 如果 start > end 且步长为正，结果为空集，不会报错 —— 容易被忽略，建议加
CASE WHEN start 防御
与表关联时注意时区和类型对齐
当用 generate_series() 生成的日期去 LEFT JOIN 日志表时，类型不一致会导致索引失效或意外过滤。例如日志表的 event_time 是 TIMESTAMP WITH TIME ZONE，而你生成的是 DATE，比较前会隐式转成 TIMESTAMP W/O TZ，可能跨时区偏移。
- 统一用
TIMESTAMP WITH TIME ZONE：把起止值写成'2024-01-01 UTC'::TIMESTAMPTZ，步长用'1 day'::INTERVAL - 避免在 ON 条件里对生成列做函数操作，比如
ON date_trunc('day', gs.dt) = log.date—— 这会让 JOIN 无法利用索引 - 如果只是补全缺失日期，建议先用 CTE 物化日期序列，再 JOIN，防止 planner 误判行数
性能提示：大范围日期生成别忘加 LIMIT
generate_series() 在内存中构造结果集，不限制范围时可能耗尽 work_mem 或拖慢查询。比如 generate_series('1970-01-01', '2100-01-01') 会产生近 5 万行，即使没后续操作也会明显卡顿。
- 业务上通常只需要未来/过去 N 天，显式加
LIMIT 365是低成本防御手段 - PostgreSQL 15 不支持在
generate_series()内部做谓词下推，所以不能写WHERE dt 来剪枝 —— 必须靠 LIMIT 或外层子查询 - 如果真要处理多年跨度（如报表维度表），建议建物化视图或普通表预存，而不是每次查都算
真正麻烦的不是语法，而是时间类型隐式转换和时区上下文 —— 同一个语句在 psql 里跑通，嵌到视图或函数里就少半天，大概率是 timestamp vs timestamptz 混用。动手前先 SELECT pg_typeof(...) 看一眼类型最省时间。
