MAKE_DATE函数严格按year、month、day顺序接收三个integer参数，不支持字符串或NULL，非法日期直接报错，性能优于字符串拼接+TO_DATE，生成列中需确保输入列NOT NULL。
MAKE_DATE函数的参数顺序和类型要求
MAKE_DATE 是 PostgreSQL 12+ 引入的日期构造函数，它严格按 year、month、day 顺序接收三个 integer 参数，不能颠倒或省略。传入非整数（比如 text 或 numeric）会报错：function make_date(integer, integer, integer) does not exist。
常见错误是把字符串直接拼进去，例如 MAKE_DATE('2024', '05', '10') —— 这会触发类型不匹配。必须显式转换：
SELECT MAKE_DATE(2024, 5, 10); -- ✅ 正确
SELECT MAKE_DATE(CAST('2024' AS integer), 5, 10); -- ✅ 转换后可用处理无效日期（如2月30日）会直接报错
MAKE_DATE 不做容错校验，遇到逻辑非法组合（如 MAKE_DATE(2024, 2, 30)）会立即抛出错误：date field value out of range: 2024-02-30。它不像 TO_DATE('2024-02-30', 'YYYY-MM-DD') 那样可能静默截断或绕过。
- 如果输入来自用户或外部表，务必先用
VALIDATE类逻辑预检，比如结合DATE_PART和LEAST/GREATEST判断天数是否超过当月最大天数 - 无法用
COALESCE或NULLIF捕获该错误；需用BEGIN ... EXCEPTION块在函数/存储过程中兜底 - 对批量数据，建议先用
WHERE过滤掉明显越界值（如day 31），再调用MAKE_DATE
与字符串拼接 + TO_DATE 的性能和可读性对比
有人习惯用字符串拼接再转日期：TO_DATE(year::text || '-' || month::text || '-' || day::text, 'YYYY-MM-DD')。这虽然能隐式容错（比如自动忽略前导零），但代价明显：
- 字符串拼接 + 解析比纯整数运算慢约 3–5 倍（实测百万行场景）
- 格式模板写错（如用
'YY-MM-DD'）会导致静默错误或意外结果 -
MAKE_DATE返回的是原生date类型，无需额外类型推导，JOIN 或索引扫描更稳定
除非你明确需要宽松解析（比如接受 '05' 和 5 混用且不想改上游数据），否则优先用 MAKE_DATE。
在INSERT或UPDATE中安全使用MAKE_DATE
直接在 INSERT 中用 MAKE_DATE 很常见，但要注意默认值或生成列（generated column）中的限制：
-
GENERATED ALWAYS AS (MAKE_DATE(year_col, month_col, day_col)) STORED是合法的，但所有参与列必须为NOT NULL，否则生成失败 - 若某列为
NULL，MAKE_DATE会报错，不能返回NULL—— 必须提前用COALESCE或CASE处理空值，例如：MAKE_DATE(COALESCE(year_col, 1970), COALESCE(month_col, 1), COALESCE(day_col, 1)) - 在
ON CONFLICT ... DO UPDATE中使用时，确保冲突键不依赖该表达式结果，否则可能引发循环依赖判断失败
最易被忽略的是：MAKE_DATE 对负数年份支持有限（如 -1 表示 1 BC），但多数业务系统不涉及，别误以为它能处理任意纪年格式。
