三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

深入解析PostgreSQL词法分析：从SQL解析到psql扩展实践

发布时间：2026/8/17 6:20:04 三亩地 编程学习日记
深入解析PostgreSQL词法分析：从SQL解析到psql扩展实践

1. 从命令行到抽象语法树：为什么需要理解psql的词法分析

当你敲下psql -U postgres -d mydb并连接到数据库，然后输入一条看似简单的 SQL 语句SELECT * FROM users WHERE id = 1;时，背后发生的故事远比屏幕上显示的几行结果要复杂得多。对于大多数开发者而言，PostgreSQL 是一个功能强大的黑盒，我们发送 SQL，它返回数据。但如果你和我一样，对数据库内核的运作机制抱有强烈的好奇心，或者正面临性能调优、自定义语法扩展、甚至是开发数据库相关工具（如 SQL 审核、ORM 深度优化）的挑战，那么深入这个“黑盒”的第一站，往往就是理解 SQL 语句是如何被“读懂”的。

这个过程始于词法分析。你可以把它想象成一位精通多国语言的速记员，他的工作不是理解整段演讲的深意，而是快速、准确地将连续的字符流，切割成一个个有意义的“单词”（在编译原理中称为 Token），并给每个单词贴上标签，比如“这是一个关键字”、“这是一个标识符”、“这是一个数字常量”。在 PostgreSQL 的生态中，负责这项工作的核心组件之一，就是psql客户端内置的前端解析器。虽然服务器端（postgres进程）有自己更复杂、更完整的解析器来处理最终执行的 SQL，但psql自身的词法分析器同样至关重要。它不仅要处理我们交互式输入的命令，还要能识别psql特有的元命令（如\dt,\c,\timing），并决定一条输入是应该发送给服务器执行，还是由客户端自己处理。

理解psql的词法分析源码，其价值远不止于满足技术好奇心。它能帮你：

  • 精准定位语法错误：当你的 SQL 在psql中报出“语法错误”时，你能大致判断是词法阶段（比如字符串没闭合）还是语法阶段（比如关键字顺序错了）的问题，排查效率更高。
  • 深入定制与扩展：如果你想为psql增加一个新的元命令（比如\mycmd），或者修改某些输入的处理逻辑，你必须从词法分析入手。
  • 理解 SQL 注入的底层原理：SQL 注入的本质就是构造特殊的字符序列，欺骗词法分析器和语法分析器，使其产生非预期的解析结果。读懂源码，你能从根源上理解各种注入手法的原理与防御边界。
  • 为学习服务器端解析打下坚实基础：psql的词法分析器相对独立和简洁，是理解 PostgreSQL 整个 SQL 处理流水线的绝佳切入点。

接下来，我将带你深入 PostgreSQL 源码的src/bin/psql/目录，聚焦于scan.l这个文件（或由它生成的scan.c），以“解剖麻雀”的方式，看看这位“速记员”是如何工作的。

2. 核心战场：scan.l 文件与 Flex 工具链

PostgreSQL 的词法分析器并非手写而成，它使用了名为Flex（Fast Lexical Analyzer Generator）的工具来自动生成。Flex 是一个词法分析器生成器，它读取我们编写的、具有特定规则的.l文件（lex 文件），然后输出纯 C 语言代码的词法分析器。在psql的源码目录（通常是src/bin/psql/）下，核心文件就是scan.l。

注意：在构建 PostgreSQL 后，你会在同一目录下看到scan.c和scan.h，它们就是由 Flex 根据scan.l生成的。直接阅读scan.l更能理解设计意图。

scan.l文件的结构非常清晰，主要分为三个部分，用%%分隔：

  1. 定义段（Definitions Section）：位于第一个%%之前。这里定义了词法分析器所需的宏、状态（Start Condition）声明，以及一些 C 代码（通常用于包含头文件、定义局部变量和函数）。对于psql来说，一个关键点是它定义了不同的“扫描状态”，比如INITIAL（初始状态）、SQL（处理 SQL 语句）、BACKSLASH（处理以反斜杠\开头的元命令）等。这允许分析器在不同的上下文中对相同的字符做出不同的解释。

  2. 规则段（Rules Section）：位于第一个%%和第二个%%之间。这是文件的核心，由一系列“模式-动作”对组成。模式是一个正则表达式，用于匹配输入字符流；动作是一段 C 代码，当匹配到对应模式时执行，通常用于返回一个 Token 类型（如IDENT、INTEGER）或执行某些特殊操作（如切换状态、忽略空白字符）。

  3. 用户子程序段（User Code Section）：位于第二个%%之后。这里可以放置一些辅助函数，这些函数可以在规则段的动作中被调用。在psql的scan.l中，这里通常比较简洁，主要逻辑都在规则段和配套的psqlscan.c等文件中。

理解这个结构是阅读源码的第一步。词法分析器本质上就是一个状态机，它根据当前状态和读入的字符，决定匹配哪个规则，执行哪个动作，并可能跳转到新的状态。psql的词法分析器之所以能同时处理 SQL 和元命令，正是依靠这种状态机机制。

3. 状态机的艺术：区分 SQL、元命令与变量

psql交互界面的一个独特之处在于，它需要处理三种主要类型的输入：

  1. SQL 语句：如SELECT * FROM table;
  2. psql 元命令：以反斜杠\开头，如\dt,\c database,\set var value
  3. psql 变量引用：以冒号:开头，如:variable_name

词法分析器必须准确区分它们。这是通过“开始条件”（Start Condition）实现的。在scan.l的定义段，你会看到类似这样的声明：

%x BACKSLASH SQL SINGLEQUOTED DOLLARQUOTED %x VARIABLE

%x表示声明的是“独占式”开始条件。当分析器处于某个独占开始条件时，只有那些前面标明了该条件的规则才会被激活。这就像给词法分析器戴上了不同的“眼镜”，戴上“SQL眼镜”时，它只关注 SQL 相关的规则；戴上“BACKSLASH眼镜”时，它只处理元命令。

那么，分析器如何决定戴上哪副“眼镜”呢？关键在于初始规则和状态切换。让我们看一个简化的流程：

  1. 启动与初始判断：分析器启动时，默认处于INITIAL状态。在INITIAL状态下，有规则专门检测输入的第一个字符。

    • 如果遇到反斜杠\，分析器会执行动作BEGIN(BACKSLASH);，这表示切换到BACKSLASH状态，开始按元命令的规则进行词法分析。
    • 如果遇到冒号:，可能会切换到VARIABLE状态来处理变量引用。
    • 否则，默认会BEGIN(SQL);，切换到SQL状态，按 SQL 词法规则进行分析。

  2. SQL 状态下的精细处理：在SQL状态下，分析器需要识别 SQL 的丰富元素。这里又有更精细的状态管理。例如：

    • 字符串常量：当在SQL状态下遇到单引号'时，一个常见的动作是BEGIN(SINGLEQUOTED);，进入SINGLEQUOTED状态。在这个状态下，分析器会忽略大多数特殊字符的规则（比如不再将SELECT视为关键字），直到遇到另一个配对的单引号，才跳出该状态，返回一个STRING类型的 Token。这确保了字符串内容中的任何字符（即使是看起来像 SQL 关键字的字符）都不会被错误地解析。
    • 美元引号字符串：PostgreSQL 支持$$或$tag$...$tag$这种形式的字符串界定符，用于避免单引号转义的麻烦。当在SQL状态下遇到$时，分析器会进入DOLLARQUOTED状态，并启动一个复杂的子状态机来匹配结束的$tag$。

  3. 元命令的解析：在BACKSLASH状态下，规则会有所不同。例如，它可能将后续的字母序列直接识别为元命令名（如dt），将空格后的内容识别为参数。元命令的结束通常以换行符为标志，而不需要 SQL 语句那样的分号;。

这种基于状态机的设计，是psql词法分析器能够清晰、无歧义地处理混合输入的关键。它确保了SELECT \dt;这样的输入会被正确地解析为：一个SELECT关键字，接着是一个名为\dt的标识符（可能引发错误），而不是将\dt当作元命令执行。

4. 规则拆解：从正则表达式到Token

规则段是scan.l最精彩的部分。每一条规则都像是一句“如果...就...”的指令。我们来看几个典型的例子，理解模式（正则表达式）如何与动作（C代码）配合。

4.1 处理空白字符与注释

这是最基础也最重要的规则之一，它确保了分析器能忽略无关的格式信息。

[ \t\n\r\f]+ { /* 忽略所有空白字符 */ }
  • 模式：[ \t\n\r\f]+。这是一个正则表达式，匹配一个或多个空格、制表符、换行符、回车符、换页符。
  • 动作：{ /* 忽略 */ }。大括号内是空的，意味着匹配到这些字符时，不产生任何 Token，直接忽略并继续读取下一个字符。这保证了SELECT * FROM table和SELECT*FROM table在词法层面被处理成相同的 Token 序列。

对于 SQL 注释，规则类似：

"--"[^\n]* { /* 忽略单行注释 */ } "/*"([^*]|\*+[^*/])*\*+"/" { /* 忽略多行（C风格）注释 */ }

注释内容同样被直接丢弃，不进入后续的语法分析阶段。

4.2 识别关键字与标识符

SQL 语言有很多保留字，如SELECT,FROM,WHERE。在词法分析中，需要将它们与普通的表名、列名（标识符）区分开。

SELECT { return SELECT_P; } FROM { return FROM_P; } WHERE { return WHERE_P; } ... [A-Za-z_][A-Za-z_0-9]* { // 这是一个标识符或未被上面规则捕获的关键字 yylval.str = strdup(yytext); return IDENT; }
  • 模式：SELECT。这是一个精确匹配字符串"SELECT"的模式。注意，Flex 的匹配是最长匹配和优先匹配的。即，它会尽可能匹配更长的字符串，并且规则在文件中出现的顺序也有优先级（靠前的规则优先）。
  • 动作：return SELECT_P;。当匹配到SELECT时，直接返回一个名为SELECT_P的 Token 类型（_P后缀常用来表示“关键字”）。这个 Token 类型是一个整数常量，定义在由语法分析器生成器（Bison）生成的psqlscan.h头文件中。
  • 标识符模式：[A-Za-z_][A-Za-z_0-9]*。这个正则表达式匹配以字母或下划线开头，后跟零个或多个字母、数字、下划线的字符串。这符合 SQL 标识符的命名规则。
  • 标识符动作：将匹配到的文本（yytext）复制一份（strdup），赋值给全局变量yylval.str（这是与语法分析器通信的联合体YYSTYPE的成员），然后返回IDENT这个 Token 类型。语法分析器收到IDENT后，可以从yylval.str中获取具体的标识符名字。

为什么SELECT不会也被标识符规则匹配？因为精确匹配SELECT的规则出现在标识符规则之前。Flex 会优先使用它，所以SELECT被识别为关键字 Token，而不是一个普通的IDENT。

4.3 处理数字、字符串和操作符

[0-9]+ { yylval.ival = atoi(yytext); return INTEGER; } [0-9]+\.[0-9]*|[0-9]*\.[0-9]+ { yylval.dval = atof(yytext); return FLOAT; } '([^']|'')*' { // 处理单引号字符串，将两个连续单引号''转义为一个单引号' yylval.str = dequote_string(yytext, '\''); return STRING; } "+"|"-"|"*"|"/"|"="|"<"|">"|"!" { return yytext[0]; } // 返回操作符字符本身
  • 数字：整数和小数有不同的模式。动作中会将字符串形式的数字转换为 C 语言的int或double类型，存入yylval，并返回相应的 Token。
  • 字符串：模式'([^']|'')*'匹配以单引号开始和结束的字符串。其中[^']匹配任何非单引号字符，''匹配两个连续的单引号（在 SQL 中这是转义一个单引号的方式）。动作中的dequote_string函数（假设存在）会处理转义，返回净化后的字符串内容。
  • 操作符：对于单字符操作符，通常直接返回该字符的 ASCII 码值作为 Token。对于多字符操作符（如<=,<>,!=），会有更具体的规则来匹配。

4.4 处理psql元命令和变量

在BACKSLASH状态下，规则会变得简单直接：

<BACKSLASH>[a-zA-Z]+ { yylval.str = strdup(yytext); return META_COMMAND; // 假设的Token类型 } <BACKSLASH>\n { BEGIN(INITIAL); // 遇到换行，元命令结束，回到初始状态 return EOL; }
  • <BACKSLASH>表示这条规则只在BACKSLASH状态下生效。
  • 匹配一串字母作为元命令名。
  • 遇到换行符\n时，不仅返回一个行结束 Token，更重要的是将状态切换回INITIAL，为解析下一条用户输入做好准备。

变量引用的处理可能在VARIABLE状态下，匹配如:var_name这样的模式，并返回VARIABLE_REF类型的 Token。

5. 实战中的挑战与调试技巧

阅读源码是理解原理，但在实际修改或调试词法分析器时，你会遇到一些典型的挑战。以下是我在接触 PostgreSQL 词法分析代码时积累的一些经验。

5.1 状态管理混乱导致的错误

这是最常见的问题之一。例如，如果你在SINGLEQUOTED（处理单引号字符串）状态下，忘记添加一条规则来处理转义的单引号''，那么字符串'It''s great'会在第一个'后进入字符串状态，然后在s后面的'处错误地退出字符串状态，导致剩下的s great'被当作普通 SQL 解析，引发语法错误。

调试方法：

  1. 添加调试输出：在scan.l规则的动作中，临时加入fprintf(stderr, "State: %d, Matched: %s\n", YY_START, yytext);。YY_START是 Flex 内部表示当前状态的宏。这能帮你清晰地看到分析器在每一步所处的状态和匹配的内容。
  2. 使用 Flex 的调试模式：编译 Flex 生成的词法分析器时，可以定义YYDEBUG宏并设置yydebug = 1;。这会使分析器运行时输出极其详细的调试信息，包括每个状态的转换和规则的匹配情况。虽然信息量大，但对于复杂问题非常有效。
  3. 绘制状态转换图：对于复杂的词法规则（尤其是处理美元引号字符串），在纸上或使用绘图工具画出状态转换图，明确每个状态在遇到哪些字符时会跳转到哪个状态。这能从根本上理清逻辑。

5.2 最长匹配与规则优先级陷阱

Flex 的“最长匹配”原则有时会产生反直觉的结果。考虑规则：

"==" { return EQ_EQ; } "=" { return EQ; }

如果你输入==，它会被正确匹配为EQ_EQ。但如果你有一个规则是[=]+（匹配一个或多个=），并且它放在"=="规则之前，那么==就会被[=]+匹配，返回的可能是单个EQToken 或者一个未知 Token，而不是你期望的EQ_EQ。

经验法则：

  • 越具体的规则放越前面。将精确匹配字符串的规则（如关键字、多字符操作符）放在通用规则（如标识符、单字符操作符）之前。
  • 谨慎使用*和+。在定义标识符、数字等模式时没问题，但在匹配操作符等场景时，要避免过于宽泛的模式“吃掉”更具体的模式。

5.3 内存管理：yylval.str 的归属

在标识符或字符串的规则动作中，我们常看到yylval.str = strdup(yytext);。yytext是 Flex 提供的指向当前匹配文本的指针，但这个指针指向的内容是临时的，可能会被后续的输入覆盖。因此，必须使用strdup（或pstrdup，PostgreSQL 内部的内存分配函数）进行复制，将字符串内容持久化。

常见的坑：忘记strdup，直接赋值yylval.str = yytext;。这会导致语法分析器拿到的字符串指针指向无效内存，结果不可预测，可能表现为随机字符、段错误等。在 PostgreSQL 源码中，通常有配套的psqlscan.c文件，里面提供了psql_scan_strdup等函数来安全地处理这个问题，阅读源码时应注意这些细节。

5.4 与语法分析器（Bison）的接口

词法分析器（Flex 生成）和语法分析器（Bison 生成）是协同工作的。它们通过三个关键元素通信：

  1. yylex()函数：这是词法分析器的入口，由语法分析器调用。每次调用，yylex()从输入流中识别一个 Token 并返回其类型。
  2. yylval全局变量：这是一个YYSTYPE类型的联合体（union），用于在返回 Token 类型的同时，传递该 Token 的“值”（比如标识符的名字、数字的值）。
  3. Token 类型常量：在 Bison 生成的*.tab.h头文件（在 PostgreSQL 中是psqlscan.h）中定义，如SELECT_P,IDENT,INTEGER等。词法分析器返回的这些整数，告诉语法分析器“我找到了一个什么东西”。

确保scan.l中返回的 Token 类型与.y语法文件中定义的完全一致，是两者正常合作的基础。任何不匹配都会导致语法分析器收到无法理解的 Token，从而报错。

6. 扩展实践：为psql添加一个简单的元命令

理论最终要服务于实践。假设我们想给psql添加一个简单的元命令\hello [name]，功能是打印 “Hello, [name]!”（如果没提供名字，就打印 “Hello, world!”）。这需要修改词法分析器和命令处理逻辑。

步骤 1：在scan.l中增加规则

首先，我们需要确保\hello能被识别。在scan.l的规则段，找到处理元命令的部分（通常在BACKSLASH状态下），添加一条规则：

<BACKSLASH>hello { yylval.str = strdup(yytext); // 存储命令名 "hello" return META_HELLO; // 返回一个自定义的Token类型 }

这里我们返回一个自定义的 Token 类型META_HELLO。接下来，这个 Token 需要被语法分析器识别。

步骤 2：在语法文件（如command.y）中声明和处理 Token

PostgreSQL 的psql元命令语法可能定义在如src/bin/psql/command.y的文件中。我们需要：

  1. 在 Token 声明部分（通常以%token开头）添加META_HELLO。
  2. 在语法规则部分，添加一条新的规则。语法规则定义了命令的结构。假设元命令的通用格式是META_COMMAND optional_args，我们可能需要添加：
    meta_command: META_HELLO opt_name { // 动作代码：调用处理hello命令的函数 do_hello($2); } ; opt_name: /* 空 */ { $$ = NULL; } | name_string { $$ = $1; } ; name_string: STRING { $$ = $1; } | IDENT { $$ = $1; } ;
    这段语法规则的意思是：一个meta_command可以是META_HELLO后面跟一个可选的opt_name。opt_name可以是空，也可以是一个字符串或标识符。当匹配到这条规则时，执行动作do_hello($2)，其中$2代表第二个语法符号（即opt_name）的值。

步骤 3：实现命令处理函数do_hello

在psql的 C 源码文件（如src/bin/psql/commands.c）中，实现do_hello函数：

static void do_hello(const char *name) { if (name == NULL || name[0] == '\0') printf("Hello, world!\n"); else printf("Hello, %s!\n", name); }

步骤 4：重新生成与编译

  1. 修改scan.l后，需要重新运行flex生成scan.c。在 PostgreSQL 的构建系统中，这通常通过make自动完成，但你需要确保构建工具链（flex, bison）已安装。
  2. 同样，修改command.y后，需要重新运行bison生成command.tab.c和command.tab.h。
  3. 最后，重新编译整个psql可执行文件。

完成以上步骤后，启动你新编译的psql，输入\hello应该会输出 “Hello, world!”，输入\hello PostgreSQL则会输出 “Hello, PostgreSQL!”。

这个过程清晰地展示了词法分析如何作为整个命令处理流程的“排头兵”：它最先接触原始输入，将其切割并贴上标签（Token），然后语法分析器根据这些标签的序列，按照预定义的语法规则进行组装和理解，最终由语义动作（如do_hello函数）执行具体的操作。

通过这样一次小小的扩展实践，你会对psql乃至整个 PostgreSQL 的“输入-解析-执行”链条有更直观、更深刻的认识。词法分析不再是源码中枯燥的字符匹配，而是连接用户意图与数据库功能的第一个，也是至关重要的一座桥梁。理解它，就等于握住了打开数据库内核世界大门的第一把钥匙。

编程学习 学习日记 实战经验
← 返回列表