SQLite和PostgreSQL虽然都声称支持SQL标准，但在内置函数层面，二者差异远比想象中大。SQLite定位于嵌入式数据库，函数库追求精简与低依赖，很多功能需要借助宿主语言处理；PostgreSQL则是功能型数据库，不仅函数数量多，还支持操作符重载、过程语言扩展和丰富的类型系统。如果仅仅按照SQLite里的写法迁移到PostgreSQL，往往会遇到类型转换失败、日期格式不符、聚合结果不一致等问题。下面从最常踩坑的几个方向展开对比。
一、日期与时间函数：看似简单，格式和时区完全不同
SQLite没有真正意义上的日期时间存储类型，日期和时间通常以TEXT、INTEGER或REAL形式保存，配合datetime()、julianday()、strftime()等函数完成生成与格式化。例如要获取当前时间，SQLite里常见写法是datetime('now')，默认返回的是UTC时间，如果需要本地时间，还要再补充一个修饰符datetime('now','localtime')。这种基于字符串修饰符的设计非常灵活，但也容易让开发者忽略时区问题。
PostgreSQL则拥有完整的日期时间类型体系，包括timestamp、timestamptz、interval等。获取当前时间可以直接使用now()或CURRENT_TIMESTAMP，返回结果受会话时区参数TimeZone影响。在格式化层面，PostgreSQL的to_char(now(), 'YYYY-MM-DD HH24:MI:SS')对应SQLite的strftime('%Y-%m-%d %H:%M:%S','now')，但两者的占位符风格完全不同，SQLite使用百分号开头的格式符，而PostgreSQL使用类似Oracle的格式模板。迁移时如果只改函数名不改占位符，得到的往往是不符合预期的字符串。
-- SQLite 获取当前时间与格式化
SELECT datetime('now');
SELECT strftime('%Y-%m-%d %H:%M:%S', 'now', 'localtime');
-- PostgreSQL 获取当前时间与格式化
SELECT now();
SELECT to_char(now(), 'YYYY-MM-DD HH24:MI:SS');
日期运算的差异同样明显。SQLite使用修饰符字符串进行日期加减，例如date('now','+1 day')表示明天，这种方式把运算规则编码进字符串参数里。PostgreSQL则使用类型化的间隔值，典型写法是now() + interval '1 day'。SQLite里并没有interval类型，不能直接使用now() + interval '1 day'这种表达式。在迁移过程中，如果系统里存在大量基于修饰符的日期计算逻辑，几乎每一处都需要手动改写为PostgreSQL的interval运算方式。
二、字符串处理与类型转换：空值传播与宽松转换的坑
字符串拼接是最常用的操作之一，但两者对NULL值的处理存在细微差别。SQLite和PostgreSQL都支持||操作符，当拼接的任意一侧为NULL时，结果同样为NULL。这种NULL传播行为虽然符合SQL规范，但在实际业务中往往不是我们希望的结果。PostgreSQL为此专门提供了concat()函数，该函数会自动忽略NULL参数，例如concat('a', NULL, 'b')返回字符串ab。SQLite在较老版本中并没有内置concat()函数，除非使用较新的版本，否则需要通过coalesce()手动处理每个参数。
-- 两者都支持 || 操作符，NULL 会传播
SELECT 'a' || NULL || 'b';
-- PostgreSQL 推荐用 concat 忽略 NULL
SELECT concat('a', NULL, 'b'); -- 返回 ab
-- SQLite 需要手动处理空值
SELECT coalesce('a','') || coalesce(NULL,'') || coalesce('b','');
除了拼接，大小写转换函数在多字节字符处理上也存在差异。SQLite的upper()和lower()默认只处理ASCII字符，对于非ASCII字符的转换结果可能不符合预期。PostgreSQL则会根据数据库编码和区域设置进行更全面的处理，对多语言文本支持更好。子串截取方面，SQLite使用substr(text, start, length)，PostgreSQL使用substring(text from start for length)，虽然索引都从1开始，但负数起始位置的行为并不一致，这也是迁移时容易忽略的细节。
类型转换是另一个重灾区。SQLite的CAST非常宽松，例如CAST('abc' AS INTEGER)会直接返回0，而不是报错。这种容忍性在嵌入式场景中可能带来便利，但也会隐藏数据质量问题。PostgreSQL的CAST则严格得多，同样的表达式会抛出invalid input syntax for type integer错误。如果把SQLite里的查询逻辑原封不动迁过去，很多原来静默返回0或空值的语句会直接失败。解决思路是在转换前用正则或NULLIF进行校验，或者使用PostgreSQL的异常处理机制。
-- SQLite 宽松：非法字符串转整数得到 0
SELECT CAST('abc' AS INTEGER); -- 返回 0
-- PostgreSQL 严格：直接报错
SELECT CAST('abc' AS INTEGER); -- ERROR: invalid input syntax for type integer
三、聚合函数与JSON函数：分组拼接和结构化输出的映射关系
分组字符串拼接在报表和标签场景中非常常见。SQLite使用group_concat()，比如group_concat(name, ',')可以把分组内所有name用逗号连接起来。PostgreSQL对应的函数是string_agg()，语法为string_agg(name, ',')。表面上看只是函数名不同，但细节上有不小差别。PostgreSQL的string_agg()支持在聚合内部使用ORDER BY子句，例如string_agg(name, ',' ORDER BY name)，可以保证拼接顺序。SQLite的group_concat()虽然也能指定分隔符，但结果顺序通常依赖底层扫描顺序，想要稳定排序一般需要先在子查询中排序再聚合。
-- SQLite 分组拼接 SELECT group_concat(name, ',') FROM users; -- PostgreSQL 分组拼接，支持内部排序 SELECT string_agg(name, ',' ORDER BY name) FROM users;
JSON函数方面，两者都提供了生成JSON结构的聚合能力，但函数命名差异较大。SQLite的json_group_array(name)返回一个JSON数组文本，json_group_object(id, name)返回以id为键、name为值的JSON对象文本。PostgreSQL对应的聚合函数是json_agg(name)和json_object_agg(id, name)，返回的是JSON类型而不是纯文本，需要时还可以再通过::text转换。需要注意的是，PostgreSQL的json_build_object()虽然也能构造JSON对象，但它处理的是单行数据而不是分组聚合，与SQLite的json_group_object()在语义上并不完全对等。
-- SQLite JSON 聚合 SELECT json_group_array(name) FROM users; SELECT json_group_object(id, name) FROM users; -- PostgreSQL JSON 聚合 SELECT json_agg(name) FROM users; SELECT json_object_agg(id, name) FROM users;
窗口函数支持度也是需要留意的点。SQLite从较新版本开始支持窗口函数，例如row_number()、rank()、lag()等，但部分高级选项和语法细节与PostgreSQL仍有差距。PostgreSQL的实现更完整，支持更丰富的窗口框架、过滤子句和聚合窗口组合。如果项目依赖窗口函数做复杂分析，迁移前最好先确认SQLite版本和目标PostgreSQL版本之间的行为差异。
四、编写跨数据库SQL的兼容策略
与其在迁移时逐个修改函数调用，不如在系统设计阶段就建立一层函数映射关系。可以维护一份SQLite到PostgreSQL的函数对照表，覆盖日期格式化、字符串处理、类型转换、聚合拼接等高频操作。对于使用ORM的项目，尽量把这类差异封装在数据访问层或查询构造器中，避免在业务代码里散落大量裸SQL函数。如果项目需要同时支持两种数据库，建议在公共模块中抽象出统一的查询接口。
PostgreSQL允许用户创建自定义SQL函数，这为模拟SQLite的部分行为提供了便利。例如可以在PostgreSQL中创建一个名为group_concat(text, text)的函数，内部封装string_agg()逻辑，这样原有业务代码中的group_concat()调用就能尽量少改动。类似地，日期格式化占位符也可以通过自定义函数进行适配，把SQLite风格的%Y-%m-%d转换成PostgreSQL的YYYY-MM-DD。这种方式虽然增加了一点维护成本，但能显著降低迁移风险。
-- 在 PostgreSQL 中模拟 SQLite 的 group_concat CREATE OR REPLACE FUNCTION group_concat(text, text) RETURNS text AS $$ SELECT string_agg($1, $2); $$ LANGUAGE SQL IMMUTABLE; -- 使用示例 SELECT group_concat(name, ',') FROM users;
最后要强调版本差异。SQLite和PostgreSQL都在持续迭代，某些函数可能在较新版本中才加入，例如SQLite在后续版本里逐步补充了更多字符串函数和JSON操作符。因此在做兼容性评估时，不能只看官方文档的通用说明，还应当针对实际部署的具体版本进行验证。搭建一个包含双数据库的回归测试环境，把关键查询和报表逻辑跑一遍，往往能比纯人工审查更早暴露函数差异带来的问题。
函数差异并不是迁移的终点，而是理解两种数据库设计取向的入口。SQLite追求极简和自包含，很多功能留给应用层解决；PostgreSQL则把大量能力下沉到数据库内部，通过类型系统和函数库提供更强的数据处理能力。梳理清楚这些差异，迁移过程就能从反复试错变成有据可循的工程化改造。
SQLite函数PostgreSQL函数数据库函数差异修改时间：2026-10-05 18:37:50