后端数据库【免费下载链接】sqlglotPython SQL Parser and Transpiler项目地址https://gitcode.com/gh_mirrors/sq/sqlglot点击查看免费下载SQLGlot 是一个用 Python 编写的 SQL 解析器与转译器transpiler支持 20 种方言的解析、转译与优化。本文以仓库根目录的 CHANGELOG.md 为骨架系统梳理 SQLGlot 从 v20 到 v30 的版本演进节奏、变更内容分类体系并重点深入解读 v30.0.0 这一里程碑式大版本中官方公布的 7 条迁移指南——涵盖 mypyc 编译加速、Rust tokenizer 移除、表达式模块包化等直接影响使用者代码的破坏性变更。读完本文你将掌握如何阅读该变更日志、如何应对 v30 升级带来的 API 变化以及如何在纯 Python 版与编译加速版sqlglot[c]之间做出选择。一、CHANGELOG 文档概览281 个版本、1.5 万行的演进档案CHANGELOG.md是 SQLGlot 项目最完整、最权威的版本演进档案全文共 15718 行按版本号 发布日期组织章节如## [v30.18.0] - 2026-09-03共记录了281 个发布版本覆盖从 2024 年 1 月的 v20.6.0 到 2026 年 9 月的 v30.18.0 的完整演进过程。每个版本章节内部变更被划分为统一的语义化分类emoji 前缀统计全文各分类出现的次数可以直观看出项目各维度的活跃程度分类章节标题含义全文出现次数### :boom: BREAKING CHANGES破坏性变更可能影响既有使用者代码155### :sparkles: New Features新功能194### :bug: Bug Fixes缺陷修复231### :recycle: Refactors代码重构75### :wrench: Chores工程杂项依赖升级、CI、工具链150### :zap: Performance Improvements性能优化11### :white_check_mark: Tests测试相关6从统计可以看出SQLGlot 的迭代以高频小步快跑为特征Bug Fixes 与 New Features 数量领先说明项目在持续扩展方言支持的同时也在快速修复兼容性问题BREAKING CHANGES 高达 155 次提示使用者升级版本时需要留意行为变化尤其是各 major 版本v26、v27、v28、v29、v30。文档中每条变更以 commit hash 为锚点注明所属模块如**executor**、**optimizer**、**parser**、**postgres**、**bigquery**等、关联 PR 编号与贡献者部分条目还通过fixes issue #xxxx/addresses issue #xxxx标注其解决的 GitHub Issue。对想要深入追踪某次具体变更的用户而言这是一种可回溯、可验证的记录方式。二、版本节奏与最近版本v30.18.0 带来了什么CHANGELOG 的开头即最新版本## [v30.18.0] - 2026-09-03。以该版本为例可以完整看到一份标准版本章节的结构2.1 破坏性变更BREAKING CHANGESv30.18.0 的破坏性变更全部集中在PostgreSQL 相关类型标注annotate与若干解析/生成行为调整上Postgres 函数类型标注为decode、Left、Reverse、Overlay、Right、Rpad、SplitPart、To_Hex、Format、Normalize、ToNumber、maketime、regexpreplace、make_timestamp、bit_or、bit_xor、localtimestamp等一系列 Postgres 函数补齐了返回类型标注。这些标注的实现可以在 sqlglot/typing/postgres.py 中找到对应代码。JSONB_CONTAINS映射为运算符修复了 Postgres 方言下 JSONB 包含关系的表达方式并新增JSONBContainsTopKey表达式。BTRIM解析为TRIMPostgres 方言中的BTRIM不再作为独立函数保留而是统一解析为标准TRIM表达式。标识符规范化调整不再规范化命名数据而非引用的标识符避免在优化过程中误改数据内容。ANALYZE/DROP支持多表解析器允许一条语句中列出多张表。MOD改为乘除级优先级解析MOD运算符的解析优先级被调整到乘除multiplicative层级并同步修正了生成时的括号处理。2.2 新功能New Featuresexecutor 模块持续扩充实现了DPIPE管道操作符sqlglot/executor/python.py 为核心执行实现、REVERSE函数加入 ENV、支持OFFSET子句、支持执行优化器拒绝重写的子查询。executor 相关代码位于 sqlglot/executor/含context.py、env.py、python.py、table.py。方言能力扩展Dremio 支持 4 参数REGEXP_SPLITClickHouse 将trimLeft/trimRight/trimBoth解析进Trim表达式、支持view()表函数BigQuery 支持数字前缀字段名Postgres 支持LOCK语句Teradata 支持mod()函数语法。explode(map)支持表值函数explode现在可以作用于 map 类型。2.3 缺陷修复Bug Fixesv30.18.0 的修复覆盖多个方言例如Trino带时区的TIME字面量解析。DuckDBJSON_VALUE箭头提取在父表达式需要时正确加括号。SQLiteRegexpLike渲染为REGEXP运算符CONCAT生成||时保留COALESCE包裹窗口帧RANGE CURRENT ROW的显式结束边界。MySQL%x、%r日期格式说明符的映射CREATE TABLE列定义支持KEY。Snowflakefilter_sql匿名函数处理、位置列引用解析、OBJECT_CONSTRUCT_KEEP_NULL中的限定通配符。ClickHouseVALUES 元组包裹幂等性、保留带引号的参数化关系、生成原生lag/lead替代lagInFrame/leadInFrame。optimizer不将 WHERE 谓词下推入后续被 RIGHT/FULL JOIN 空值扩展的源不剪除 GROUP BY/HAVING/QUALIFY 引用的列_traverse_union中抛OptimizeError而非破坏作用域图sqlglot/optimizer/scope.py。parserGRANT/REVOKE无权限列表时不再抛ValueError。这类细节正是 CHANGELOG 的价值所在升级 SQLGlot 前扫描目标版本与当前版本之间的 Bug Fixes 列表即可预判哪些 SQL 行为可能发生变化。三、v30.0.0 迁移指南详解性能优先的大版本重构在整个 CHANGELOG 中## [v30.0.0] - 2026-03-16第 1902 行起是一个特殊的版本章节——它不仅罗列变更还附带了完整的Migration Guide迁移指南。该版本的核心目标是性能与编译库的多个核心组件开始支持由 mypyc 编译安装[c]extra 后可获得显著加速但这要求重构若干内部模块从而对依赖内部 API、子类化 Parser 或从内部路径导入的用户引入了破坏性变更。官方同时给出了清晰的适用范围说明如果只使用公共 APIsqlglot.parse、sqlglot.parse_one、sqlglot.transpile、sqlglot.exp.*、sqlglot.optimizer.*绝大多数代码无需改动即可升级。3.1 Rust tokenizer 移除用[c]替代[rs]v30 之前项目曾提供 Rust 编写的 tokenizersqlglotrsv29 起被移除替换为 mypyc 编译的 C 扩展sqlglotc# 之前 pip install sqlglot[rs] # 之后 pip install sqlglot[c]其中[rs]extra 仍然可以安装但已退化为废弃的 no-op 桩。被移除的 API 包括Tokenizer上的use_rs_tokenizer参数与属性RsTokenizer、RsTokenizerSettings、RsTokenTypeSettings导入tokens.py中的USE_RS_TOKENIZER常量这一点在当前仓库的 setup.py 中有直接印证extras_require中rsextra 被注释为 Deprecated: the Rust tokenizer has been replaced by sqlglotc其内容为[sqlglotrs0.13.0, fsqlglotc{version}; python_version 3.10]而cextra 则为[fsqlglotc{version}; python_version 3.10]。注意sqlglotc需要在用户机器上从源码编译且要求 Python 3.10在 Python 3.9 上pip install sqlglot[c]是 no-op只会得到纯 Python 版。独立的编译分发目录见 sqlglotc/内含 pyproject.toml 与 setup.py。3.2expressions.py拆分为包原来单文件的sqlglot/expressions.py被拆分为sqlglot/expressions/包按职责划分出 15 个子模块。该拆分在当前仓库的 sqlglot/expressions/ 目录中即可直接验证模块内容core.pyExpr、Expression、Condition、Func、AggFunc、Column、Literal等datatypes.pyDataType、DType、DataTypeParam、Intervalquery.pySelect、Query、SetOperation、UDTF、Subqueryddl.pyCreate、Alter、Drop等 DDL 语句dml.pyInsert、Update、Delete、Mergeproperties.py所有*Property类、PropertiesLocationconstraints.py所有*ColumnConstraint类math.py算术运算符Add、Sub、Mul、Div等string.py字符串函数Concat、Length、Upper等temporal.py日期/时间函数DateAdd、DateDiff等aggregate.py聚合函数Count、Sum、Avg等array.py数组函数ArrayAgg、Explode等json.pyJSON 函数JSONExtract等functions.py其他函数Coalesce、If、Case、Cast等builders.pyBuilder 辅助函数select()、from_()、condition()等向后兼容性from sqlglot.expressions import *与from sqlglot import expressions as exp仍然可用因为所有符号都从expressions/__init__.py重新导出。但如果你依赖sqlglot.expressions是单文件这一事实例如检查__file__属性该行为会被打破。3.3Parser.expression()不再接受**kwargs该变更影响所有子类化Parser或在自定义 parse 方法中调用self.expression()的代码。调用方式从传 kwargs改为直接构造表达式实例# 之前 self.expression(exp.Select, distinctTrue, expressionscols) # 之后 self.expression(exp.Select(distinctTrue, expressionscols))变更动机是消除**kwargs字典分配的开销——这与 v30 整体的性能优化目标一致。解析器的基类定义位于 sqlglot/parser.py各方言解析器位于 sqlglot/parsers/。3.4 作用域遍历bfs参数移除Scope相关遍历函数的bfs参数被删除遍历方式固定为深度优先DFS# 之前 scope.walk(bfsTrue) scope.find(exp.Column, bfsFalse) walk_in_scope(expr, bfsTrue) # 之后 scope.walk() scope.find(exp.Column) walk_in_scope(expr)行为变化旧版本默认是bfsTrue现在统一为 DFS因此依赖 BFS 顺序的代码会得到不同顺序的结果。受影响函数包括Scope.walk()、Scope.find()、Scope.find_all()、walk_in_scope()、find_in_scope()、find_all_in_scope()。作用域分析的核心实现在 sqlglot/optimizer/scope.py。3.5 Dialect 元类不再修改 Parser token 集合旧版_Dialect元类会在类创建时根据方言标志如SUPPORTS_SEMI_ANTI_JOIN动态修改解析器的 token 集合ID_VAR_TOKENS、TABLE_ALIAS_TOKENS、NO_PAREN_FUNCTIONS。这些动态修改已被移除每个 parser 现在静态声明自己的 token 集合。具体变化Dialect.SUPPORTS_SEMI_ANTI_JOIN已删除。SHOW_TRIE/SET_TRIE不再由SHOW_PARSERS/SET_PARSERS自动计算。方言与解析器的基类分别在 sqlglot/dialects/dialect.py 与 sqlglot/parsers/base.py。3.6 用Expr替代Expression做通用isinstance检查Func、Condition、Binary等 trait 基类现在直接继承自Expr而非Expression因此isinstance(node, exp.Expression)不再能匹配这些 trait 类。若代码需要判断是否为任意 AST 节点应改用exp.Expr# 之前 isinstance(node, exp.Expression) # 之后 isinstance(node, exp.Expr)3.7 编译类无法被子类化使用[c]时安装sqlglot[c]后大量核心类经由 mypyc 编译。编译后的类不能在运行时被继承——类定义本身不会报错但实例化时会抛出TypeError: interpreted classes cannot inherit from compiled。官方给出的受影响清单如下被编译不可子类化类是否可子类化所有 parserBigQueryParser、SnowflakeParser等否Parser基类否Expression、Expr及所有 AST 节点Select、Column、Func等否MappingSchema、AbstractMappingSchema否Scope否优化器规则scope.py、qualify.py、qualify_columns.py等否未被编译仍可子类化类是否可子类化Generator及所有方言生成器是Tokenizer及所有方言 tokenizer是Dialect及所有方言类是选择建议如果需要子类化 parser、表达式或 schema 等编译类请安装纯 Python 版如果需要更高执行性能且不涉及子类化则安装编译版pip install sqlglot # 纯 Python —— 完整子类化支持 pip install sqlglot[c] # 编译版 —— 更快但不可子类化四、从 CHANGELOG 反推项目架构演进CHANGELOG 不仅是版本记录也是理解项目架构演进的线索。结合仓库目录结构可以交叉验证几个重要结论表达式体系包化v30.0.0 描述的expressions拆分已完整落地于 sqlglot/expressions/且从aggregate.py、array.py、json.py、temporal.py等子模块可以看出表达式按函数族聚合、数组、JSON、时间做了职责分离。类型标注成为一等公民v30 多个版本中反复出现的 annotate xxx for postgres / mysql / spark 变更对应仓库中独立的 sqlglot/typing/ 目录其中按方言组织了 13 个类型标注模块postgres.py、mysql.py、spark.py、bigquery.py、snowflake.py等。这解释了为何 CHANGELOG 中 annotate 类 PR 如此密集——类型推断能力是 SQLGlot 优化与执行链路的基础。executor 模块快速成长v30.18.0 中**executor**前缀的变更DPIPE、OFFSET、REVERSE、子查询求值、NULL 语义修正表明 SQLGlot 正在把解析-优化链路延伸到执行能力对应 sqlglot/executor/ 的实现。方言覆盖广度CHANGELOG 中出现的方言模块trino、duckdb、mysql、clickhouse、bigquery、snowflake、sqlite、postgres、dremio、teradata、starrocks 等与 sqlglot/dialects/、sqlglot/parsers/、sqlglot/generators/ 三组目录一一对应每个方言都是解析器 生成器 方言定义三位一体的结构。优化器规则演进CHANGELOG 中大量涉及谓词下推、投影剪除、join 优化、作用域修正的变更都能在 sqlglot/optimizer/ 中找到对应的规则模块如pushdown_predicates.py、pushdown_projections.py、optimize_joins.py、qualify.py、eliminate_subqueries.py。五、如何在实际工作中用好这份 CHANGELOG5.1 定位行为变化升级 SQLGlot 前重点查看从当前版本到目标版本之间所有### :boom: BREAKING CHANGES章节。从 155 次的出现频率看任何跨 minor/major 的升级都应检查该列表。同时注意标注了fixes issue #xxxx的条目——这些通常是真实用户报告并修复的边界情况可能与你的 SQL 场景直接相关。5.2 按模块筛选关注点每个条目都带模块前缀例如**optimizer**、**executor**、**postgres**、**bigquery**。如果你只关心某个方言或某个子系统的行为可以按前缀聚焦阅读再结合对应源码目录如 sqlglot/dialects/postgres.py、sqlglot/optimizer/验证具体实现。5.3 验证安装方式与版本前提阅读 CHANGELOG 中涉及安装方式的内容时应以当前仓库的 setup.py 为准devextra 包含 duckdb、pandas、pdoc、pre-commit、ruff 等开发依赖cextra 安装sqlglotc需 Python 3.10rsextra 已废弃。版本号由 setuptools_scm 从 git 标签生成version get_version(local_schemeno-local-version)与 CHANGELOG 的版本章节一一对应。5.4 追踪测试佐证CHANGELOG 记录的方言级行为变化大多能在 tests/dialects/ 下的方言测试如 test_postgres.py、test_clickhouse.py以及 tests/ 的优化器/执行器测试中找到对应用例。需要深入验证某次修复时可以沿CHANGELOG 条目 → 方言测试 → 解析器/生成器实现的路径层层下钻。结语CHANGELOG.md之于 SQLGlot既是发布日志也是架构演进史与技术决策文档。它以 281 个版本、155 次破坏性变更和数百次方言级修复完整记录了项目从纯解析/转译走向解析 优化 类型推断 执行一体化平台的过程。其中 v30.0.0 的迁移指南尤其值得细读——它揭示了当前版本在性能mypyc 编译与灵活性子类化能力之间的明确取舍也为所有基于 SQLGlot 二次开发的用户提供了升级路径的行动清单。赞分享后端数据库【免费下载链接】sqlglotPython SQL Parser and Transpiler项目地址https://gitcode.com/gh_mirrors/sq/sqlglot点击查看免费下载相关推荐mini.nvim 变更日志深度解读从 0.1.0 到 0.19.0-dev 的演进脉络与升级指南mini.nvim 变更日志深度解读从 0.1.0 到 0.19.0 dev 的演进脉络与升级指南 本文基于 CHANGELOG.md https://lin开发工具编辑器RuboCop 官方变更日志深度解读从 v1.0 到 v1.91 的演进脉络与升级指南RuboCop 官方变更日志深度解读从 v1.0 到 v1.91 的演进脉络与升级指南 CHANGELOG.md 是 RuboCop 项目的权威版本变更记录代码质量Lint格式化静态分析开发工具Feast 变更日志深度解读从 v0.0.1 到 v0.66.0 的八年演进与技术脉络Feast 变更日志深度解读从 v0.0.1 到 v0.66.0 的八年演进与技术脉络 本指南以仓库根目录的 CHANGELOG.md https://linMLOps后端数据工程上一篇Rust模板引擎对比为什么Handlebars-rust是你的最佳选择下一篇开源项目安装与配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SQLGlot 变更日志深度解读：从 v20 到 v30 的演进脉络与 v30.0.0 迁移指南
后端数据库【免费下载链接】sqlglotPython SQL Parser and Transpiler项目地址https://gitcode.com/gh_mirrors/sq/sqlglot点击查看免费下载SQLGlot 是一个用 Python 编写的 SQL 解析器与转译器transpiler支持 20 种方言的解析、转译与优化。本文以仓库根目录的 CHANGELOG.md 为骨架系统梳理 SQLGlot 从 v20 到 v30 的版本演进节奏、变更内容分类体系并重点深入解读 v30.0.0 这一里程碑式大版本中官方公布的 7 条迁移指南——涵盖 mypyc 编译加速、Rust tokenizer 移除、表达式模块包化等直接影响使用者代码的破坏性变更。读完本文你将掌握如何阅读该变更日志、如何应对 v30 升级带来的 API 变化以及如何在纯 Python 版与编译加速版sqlglot[c]之间做出选择。一、CHANGELOG 文档概览281 个版本、1.5 万行的演进档案CHANGELOG.md是 SQLGlot 项目最完整、最权威的版本演进档案全文共 15718 行按版本号 发布日期组织章节如## [v30.18.0] - 2026-09-03共记录了281 个发布版本覆盖从 2024 年 1 月的 v20.6.0 到 2026 年 9 月的 v30.18.0 的完整演进过程。每个版本章节内部变更被划分为统一的语义化分类emoji 前缀统计全文各分类出现的次数可以直观看出项目各维度的活跃程度分类章节标题含义全文出现次数### :boom: BREAKING CHANGES破坏性变更可能影响既有使用者代码155### :sparkles: New Features新功能194### :bug: Bug Fixes缺陷修复231### :recycle: Refactors代码重构75### :wrench: Chores工程杂项依赖升级、CI、工具链150### :zap: Performance Improvements性能优化11### :white_check_mark: Tests测试相关6从统计可以看出SQLGlot 的迭代以高频小步快跑为特征Bug Fixes 与 New Features 数量领先说明项目在持续扩展方言支持的同时也在快速修复兼容性问题BREAKING CHANGES 高达 155 次提示使用者升级版本时需要留意行为变化尤其是各 major 版本v26、v27、v28、v29、v30。文档中每条变更以 commit hash 为锚点注明所属模块如**executor**、**optimizer**、**parser**、**postgres**、**bigquery**等、关联 PR 编号与贡献者部分条目还通过fixes issue #xxxx/addresses issue #xxxx标注其解决的 GitHub Issue。对想要深入追踪某次具体变更的用户而言这是一种可回溯、可验证的记录方式。二、版本节奏与最近版本v30.18.0 带来了什么CHANGELOG 的开头即最新版本## [v30.18.0] - 2026-09-03。以该版本为例可以完整看到一份标准版本章节的结构2.1 破坏性变更BREAKING CHANGESv30.18.0 的破坏性变更全部集中在PostgreSQL 相关类型标注annotate与若干解析/生成行为调整上Postgres 函数类型标注为decode、Left、Reverse、Overlay、Right、Rpad、SplitPart、To_Hex、Format、Normalize、ToNumber、maketime、regexpreplace、make_timestamp、bit_or、bit_xor、localtimestamp等一系列 Postgres 函数补齐了返回类型标注。这些标注的实现可以在 sqlglot/typing/postgres.py 中找到对应代码。JSONB_CONTAINS映射为运算符修复了 Postgres 方言下 JSONB 包含关系的表达方式并新增JSONBContainsTopKey表达式。BTRIM解析为TRIMPostgres 方言中的BTRIM不再作为独立函数保留而是统一解析为标准TRIM表达式。标识符规范化调整不再规范化命名数据而非引用的标识符避免在优化过程中误改数据内容。ANALYZE/DROP支持多表解析器允许一条语句中列出多张表。MOD改为乘除级优先级解析MOD运算符的解析优先级被调整到乘除multiplicative层级并同步修正了生成时的括号处理。2.2 新功能New Featuresexecutor 模块持续扩充实现了DPIPE管道操作符sqlglot/executor/python.py 为核心执行实现、REVERSE函数加入 ENV、支持OFFSET子句、支持执行优化器拒绝重写的子查询。executor 相关代码位于 sqlglot/executor/含context.py、env.py、python.py、table.py。方言能力扩展Dremio 支持 4 参数REGEXP_SPLITClickHouse 将trimLeft/trimRight/trimBoth解析进Trim表达式、支持view()表函数BigQuery 支持数字前缀字段名Postgres 支持LOCK语句Teradata 支持mod()函数语法。explode(map)支持表值函数explode现在可以作用于 map 类型。2.3 缺陷修复Bug Fixesv30.18.0 的修复覆盖多个方言例如Trino带时区的TIME字面量解析。DuckDBJSON_VALUE箭头提取在父表达式需要时正确加括号。SQLiteRegexpLike渲染为REGEXP运算符CONCAT生成||时保留COALESCE包裹窗口帧RANGE CURRENT ROW的显式结束边界。MySQL%x、%r日期格式说明符的映射CREATE TABLE列定义支持KEY。Snowflakefilter_sql匿名函数处理、位置列引用解析、OBJECT_CONSTRUCT_KEEP_NULL中的限定通配符。ClickHouseVALUES 元组包裹幂等性、保留带引号的参数化关系、生成原生lag/lead替代lagInFrame/leadInFrame。optimizer不将 WHERE 谓词下推入后续被 RIGHT/FULL JOIN 空值扩展的源不剪除 GROUP BY/HAVING/QUALIFY 引用的列_traverse_union中抛OptimizeError而非破坏作用域图sqlglot/optimizer/scope.py。parserGRANT/REVOKE无权限列表时不再抛ValueError。这类细节正是 CHANGELOG 的价值所在升级 SQLGlot 前扫描目标版本与当前版本之间的 Bug Fixes 列表即可预判哪些 SQL 行为可能发生变化。三、v30.0.0 迁移指南详解性能优先的大版本重构在整个 CHANGELOG 中## [v30.0.0] - 2026-03-16第 1902 行起是一个特殊的版本章节——它不仅罗列变更还附带了完整的Migration Guide迁移指南。该版本的核心目标是性能与编译库的多个核心组件开始支持由 mypyc 编译安装[c]extra 后可获得显著加速但这要求重构若干内部模块从而对依赖内部 API、子类化 Parser 或从内部路径导入的用户引入了破坏性变更。官方同时给出了清晰的适用范围说明如果只使用公共 APIsqlglot.parse、sqlglot.parse_one、sqlglot.transpile、sqlglot.exp.*、sqlglot.optimizer.*绝大多数代码无需改动即可升级。3.1 Rust tokenizer 移除用[c]替代[rs]v30 之前项目曾提供 Rust 编写的 tokenizersqlglotrsv29 起被移除替换为 mypyc 编译的 C 扩展sqlglotc# 之前 pip install sqlglot[rs] # 之后 pip install sqlglot[c]其中[rs]extra 仍然可以安装但已退化为废弃的 no-op 桩。被移除的 API 包括Tokenizer上的use_rs_tokenizer参数与属性RsTokenizer、RsTokenizerSettings、RsTokenTypeSettings导入tokens.py中的USE_RS_TOKENIZER常量这一点在当前仓库的 setup.py 中有直接印证extras_require中rsextra 被注释为 Deprecated: the Rust tokenizer has been replaced by sqlglotc其内容为[sqlglotrs0.13.0, fsqlglotc{version}; python_version 3.10]而cextra 则为[fsqlglotc{version}; python_version 3.10]。注意sqlglotc需要在用户机器上从源码编译且要求 Python 3.10在 Python 3.9 上pip install sqlglot[c]是 no-op只会得到纯 Python 版。独立的编译分发目录见 sqlglotc/内含 pyproject.toml 与 setup.py。3.2expressions.py拆分为包原来单文件的sqlglot/expressions.py被拆分为sqlglot/expressions/包按职责划分出 15 个子模块。该拆分在当前仓库的 sqlglot/expressions/ 目录中即可直接验证模块内容core.pyExpr、Expression、Condition、Func、AggFunc、Column、Literal等datatypes.pyDataType、DType、DataTypeParam、Intervalquery.pySelect、Query、SetOperation、UDTF、Subqueryddl.pyCreate、Alter、Drop等 DDL 语句dml.pyInsert、Update、Delete、Mergeproperties.py所有*Property类、PropertiesLocationconstraints.py所有*ColumnConstraint类math.py算术运算符Add、Sub、Mul、Div等string.py字符串函数Concat、Length、Upper等temporal.py日期/时间函数DateAdd、DateDiff等aggregate.py聚合函数Count、Sum、Avg等array.py数组函数ArrayAgg、Explode等json.pyJSON 函数JSONExtract等functions.py其他函数Coalesce、If、Case、Cast等builders.pyBuilder 辅助函数select()、from_()、condition()等向后兼容性from sqlglot.expressions import *与from sqlglot import expressions as exp仍然可用因为所有符号都从expressions/__init__.py重新导出。但如果你依赖sqlglot.expressions是单文件这一事实例如检查__file__属性该行为会被打破。3.3Parser.expression()不再接受**kwargs该变更影响所有子类化Parser或在自定义 parse 方法中调用self.expression()的代码。调用方式从传 kwargs改为直接构造表达式实例# 之前 self.expression(exp.Select, distinctTrue, expressionscols) # 之后 self.expression(exp.Select(distinctTrue, expressionscols))变更动机是消除**kwargs字典分配的开销——这与 v30 整体的性能优化目标一致。解析器的基类定义位于 sqlglot/parser.py各方言解析器位于 sqlglot/parsers/。3.4 作用域遍历bfs参数移除Scope相关遍历函数的bfs参数被删除遍历方式固定为深度优先DFS# 之前 scope.walk(bfsTrue) scope.find(exp.Column, bfsFalse) walk_in_scope(expr, bfsTrue) # 之后 scope.walk() scope.find(exp.Column) walk_in_scope(expr)行为变化旧版本默认是bfsTrue现在统一为 DFS因此依赖 BFS 顺序的代码会得到不同顺序的结果。受影响函数包括Scope.walk()、Scope.find()、Scope.find_all()、walk_in_scope()、find_in_scope()、find_all_in_scope()。作用域分析的核心实现在 sqlglot/optimizer/scope.py。3.5 Dialect 元类不再修改 Parser token 集合旧版_Dialect元类会在类创建时根据方言标志如SUPPORTS_SEMI_ANTI_JOIN动态修改解析器的 token 集合ID_VAR_TOKENS、TABLE_ALIAS_TOKENS、NO_PAREN_FUNCTIONS。这些动态修改已被移除每个 parser 现在静态声明自己的 token 集合。具体变化Dialect.SUPPORTS_SEMI_ANTI_JOIN已删除。SHOW_TRIE/SET_TRIE不再由SHOW_PARSERS/SET_PARSERS自动计算。方言与解析器的基类分别在 sqlglot/dialects/dialect.py 与 sqlglot/parsers/base.py。3.6 用Expr替代Expression做通用isinstance检查Func、Condition、Binary等 trait 基类现在直接继承自Expr而非Expression因此isinstance(node, exp.Expression)不再能匹配这些 trait 类。若代码需要判断是否为任意 AST 节点应改用exp.Expr# 之前 isinstance(node, exp.Expression) # 之后 isinstance(node, exp.Expr)3.7 编译类无法被子类化使用[c]时安装sqlglot[c]后大量核心类经由 mypyc 编译。编译后的类不能在运行时被继承——类定义本身不会报错但实例化时会抛出TypeError: interpreted classes cannot inherit from compiled。官方给出的受影响清单如下被编译不可子类化类是否可子类化所有 parserBigQueryParser、SnowflakeParser等否Parser基类否Expression、Expr及所有 AST 节点Select、Column、Func等否MappingSchema、AbstractMappingSchema否Scope否优化器规则scope.py、qualify.py、qualify_columns.py等否未被编译仍可子类化类是否可子类化Generator及所有方言生成器是Tokenizer及所有方言 tokenizer是Dialect及所有方言类是选择建议如果需要子类化 parser、表达式或 schema 等编译类请安装纯 Python 版如果需要更高执行性能且不涉及子类化则安装编译版pip install sqlglot # 纯 Python —— 完整子类化支持 pip install sqlglot[c] # 编译版 —— 更快但不可子类化四、从 CHANGELOG 反推项目架构演进CHANGELOG 不仅是版本记录也是理解项目架构演进的线索。结合仓库目录结构可以交叉验证几个重要结论表达式体系包化v30.0.0 描述的expressions拆分已完整落地于 sqlglot/expressions/且从aggregate.py、array.py、json.py、temporal.py等子模块可以看出表达式按函数族聚合、数组、JSON、时间做了职责分离。类型标注成为一等公民v30 多个版本中反复出现的 annotate xxx for postgres / mysql / spark 变更对应仓库中独立的 sqlglot/typing/ 目录其中按方言组织了 13 个类型标注模块postgres.py、mysql.py、spark.py、bigquery.py、snowflake.py等。这解释了为何 CHANGELOG 中 annotate 类 PR 如此密集——类型推断能力是 SQLGlot 优化与执行链路的基础。executor 模块快速成长v30.18.0 中**executor**前缀的变更DPIPE、OFFSET、REVERSE、子查询求值、NULL 语义修正表明 SQLGlot 正在把解析-优化链路延伸到执行能力对应 sqlglot/executor/ 的实现。方言覆盖广度CHANGELOG 中出现的方言模块trino、duckdb、mysql、clickhouse、bigquery、snowflake、sqlite、postgres、dremio、teradata、starrocks 等与 sqlglot/dialects/、sqlglot/parsers/、sqlglot/generators/ 三组目录一一对应每个方言都是解析器 生成器 方言定义三位一体的结构。优化器规则演进CHANGELOG 中大量涉及谓词下推、投影剪除、join 优化、作用域修正的变更都能在 sqlglot/optimizer/ 中找到对应的规则模块如pushdown_predicates.py、pushdown_projections.py、optimize_joins.py、qualify.py、eliminate_subqueries.py。五、如何在实际工作中用好这份 CHANGELOG5.1 定位行为变化升级 SQLGlot 前重点查看从当前版本到目标版本之间所有### :boom: BREAKING CHANGES章节。从 155 次的出现频率看任何跨 minor/major 的升级都应检查该列表。同时注意标注了fixes issue #xxxx的条目——这些通常是真实用户报告并修复的边界情况可能与你的 SQL 场景直接相关。5.2 按模块筛选关注点每个条目都带模块前缀例如**optimizer**、**executor**、**postgres**、**bigquery**。如果你只关心某个方言或某个子系统的行为可以按前缀聚焦阅读再结合对应源码目录如 sqlglot/dialects/postgres.py、sqlglot/optimizer/验证具体实现。5.3 验证安装方式与版本前提阅读 CHANGELOG 中涉及安装方式的内容时应以当前仓库的 setup.py 为准devextra 包含 duckdb、pandas、pdoc、pre-commit、ruff 等开发依赖cextra 安装sqlglotc需 Python 3.10rsextra 已废弃。版本号由 setuptools_scm 从 git 标签生成version get_version(local_schemeno-local-version)与 CHANGELOG 的版本章节一一对应。5.4 追踪测试佐证CHANGELOG 记录的方言级行为变化大多能在 tests/dialects/ 下的方言测试如 test_postgres.py、test_clickhouse.py以及 tests/ 的优化器/执行器测试中找到对应用例。需要深入验证某次修复时可以沿CHANGELOG 条目 → 方言测试 → 解析器/生成器实现的路径层层下钻。结语CHANGELOG.md之于 SQLGlot既是发布日志也是架构演进史与技术决策文档。它以 281 个版本、155 次破坏性变更和数百次方言级修复完整记录了项目从纯解析/转译走向解析 优化 类型推断 执行一体化平台的过程。其中 v30.0.0 的迁移指南尤其值得细读——它揭示了当前版本在性能mypyc 编译与灵活性子类化能力之间的明确取舍也为所有基于 SQLGlot 二次开发的用户提供了升级路径的行动清单。赞分享后端数据库【免费下载链接】sqlglotPython SQL Parser and Transpiler项目地址https://gitcode.com/gh_mirrors/sq/sqlglot点击查看免费下载相关推荐mini.nvim 变更日志深度解读从 0.1.0 到 0.19.0-dev 的演进脉络与升级指南mini.nvim 变更日志深度解读从 0.1.0 到 0.19.0 dev 的演进脉络与升级指南 本文基于 CHANGELOG.md https://lin开发工具编辑器RuboCop 官方变更日志深度解读从 v1.0 到 v1.91 的演进脉络与升级指南RuboCop 官方变更日志深度解读从 v1.0 到 v1.91 的演进脉络与升级指南 CHANGELOG.md 是 RuboCop 项目的权威版本变更记录代码质量Lint格式化静态分析开发工具Feast 变更日志深度解读从 v0.0.1 到 v0.66.0 的八年演进与技术脉络Feast 变更日志深度解读从 v0.0.1 到 v0.66.0 的八年演进与技术脉络 本指南以仓库根目录的 CHANGELOG.md https://linMLOps后端数据工程上一篇Rust模板引擎对比为什么Handlebars-rust是你的最佳选择下一篇开源项目安装与配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考