Npgsql.EntityFrameworkCore.PostgreSQL 中执行原生SQL脚本时双花括号解析问题解析

在使用Npgsql.EntityFrameworkCore.PostgreSQL执行原生SQL脚本时，开发者可能会遇到"failure to parse near offset X. expected an ascii digit"的错误。这个问题通常与SQL脚本中的花括号({})处理机制有关，需要理解EF Core和C#字符串处理的交互原理。

问题背景

当开发者在EF Core中使用ExecuteSqlRawAsync方法执行包含JSON操作的PostgreSQL脚本时，特别是涉及jsonb_set函数调用时，容易出现解析错误。这是因为存在两个层面的字符串处理机制：

1. C#层面的字符串插值处理
2. EF Core层面的参数化查询处理

深层原因分析

在示例代码中，开发者使用了C#的逐字字符串插值($@)来定义SQL脚本。当脚本中包含jsonb_set('{{}}'这样的语法时：

1. 首先C#会将双花括号{{}}解释为转义，实际存储为单花括号{}
2. 然后EF Core的ExecuteSqlRawAsync方法又会尝试将剩余的花括号解释为参数占位符

这种双重解释导致了最终的语法解析错误。

解决方案

有两种推荐解决方案：

方案一：增加花括号转义层级

将原始脚本中的：

jsonb_set('{{}}'::jsonb, ('{{' || sys_period || '}}')::text[], ...)

修改为：

jsonb_set('{{{{}}}}'::jsonb, ('{{{{' || sys_period || '}}}}')::text[], ...)

这样经过C#和EF Core两层解析后，能保留正确的花括号数量。

方案二：使用C#原生字符串字面量

更现代的解决方案是使用C# 11引入的三引号(""")原生字符串字面量：

private readonly string _createVersioningFunctionScript = """
    create or replace function versioning()...
    -- 这里可以直接使用标准的双花括号
    jsonb_set('{{}}'::jsonb, ('{{' || sys_period || '}}')::text[], ...)
    """;

这种方法不仅解决了花括号问题，还能保持SQL脚本的原生格式，提高可读性。

最佳实践建议

1. 对于复杂SQL脚本，优先考虑使用原生字符串字面量
2. 在必须使用插值字符串时，明确了解各层的转义规则
3. 考虑将大型SQL脚本存储在外部文件中，通过资源方式加载
4. 对于频繁执行的脚本，可以预编译为存储过程

技术延伸

这个问题实际上反映了现代开发中多层抽象带来的复杂性。从C#语言到EF Core再到PostgreSQL驱动，每一层都有自己的字符串处理规则。理解这些规则间的交互，是成为高级.NET开发者的必经之路。

类似的原理也适用于其他ORM工具和数据库驱动，掌握这种多层转义思维，能帮助开发者快速解决各类SQL执行问题。