如何用原生Jinja实现SQL WHERE IN子句参数化（无需Superset）

要在原生Jinja中实现SQL查询里IN子句的参数化，把固定的('a', 'b', 'c')替换为可传入列表["a", "b", "c"]的形式，核心是利用Jinja的过滤器对列表进行格式化处理，以下是具体实现方案：

基础实现 #

假设传入的列表变量名为target_names，可以通过Jinja的map和join过滤器将列表转换为符合SQL语法的字符串：

SELECT * FROM table
WHERE name IN ({{ target_names | map('string') | map('replace', "'", "''") | join(', ') }})

各过滤器作用说明：

• map('string')：确保列表中所有元素都被转为字符串类型，避免非字符串元素导致的语法错误
• map('replace', "'", "''")：转义元素中的单引号，防止SQL注入风险和SQL语法错误
• join(', ')：将处理后的元素用逗号分隔，拼接成'a', 'b', 'c'这样的格式

处理空列表场景 #

如果传入的列表为空，上面的写法会生成IN ()这种非法SQL语法，需要添加条件判断来兼容：

场景1：空列表时不返回任何数据 #

SELECT * FROM table
{% if target_names %}
WHERE name IN ({{ target_names | map('string') | map('replace', "'", "''") | join(', ') }})
{% else %}
WHERE 1=0
{% endif %}

场景2：空列表时返回所有数据 #

SELECT * FROM table
WHERE {% if target_names %}name IN ({{ target_names | map('string') | map('replace', "'", "''") | join(', ') }}){% else %}1=1{% endif %}

注意事项 #

• 该方法通过转义单引号避免基础SQL注入，但如果你的数据库有其他特殊字符需要处理，需对应调整转义逻辑
• 若追求更安全的参数化，建议结合数据库驱动的预编译语句，但原生Jinja环境下上述方案是最直接的实现方式

内容的提问来源于stack exchange，提问作者eng2019