SQL 是一种强类型语言。也就是说，每个数据项都有一个相关联的数据类型，它决定了该数据项的行为和允许的用法。 Postgres 拥有一个可扩展的类型系统，比其他 RDBMS 实现更加通用和灵活。因此，Postgres 中大部分类型转换行为应当由一般规则而不是 ad-hoc（特定）启发式规则支配，以使混合类型表达式即使在有用户定义类型时也有意义。

Postgres 的扫描器/解析器只把词法元素解码成五种基本类别：整数、浮点数、字符串、名字和关键字。大多数扩展类型首先被词法化为字符串。SQL 语言定义允许用字符串指定类型名，这一机制可以用来让解析器走上正确的路径。例如，查询

tgl=> SELECT text 'Origin' AS "Label", point '(0,0)' AS "Value";
 Label  | Value
--------+-------
 Origin | (0,0)
(1 row)

中有两个字符串，类型分别为 text 和 point。如果没有为字符串指定类型，则最初会赋予占位类型 unknown（未知），并在后面阶段按如下所述解析。

在 Postgres 解析器中有四种基本的 SQL 结构需要专门的类型转换规则：

操作符: Postgres 允许带左一元和右一元（单参数）操作符的表达式，也允许二元（双参数）操作符的表达式。
函数调用: Postgres 类型系统的很大一部分是围绕一套丰富的函数构建的。函数调用有一个或多个参数，对任何具体的查询，这些参数都必须与系统目录中可用的函数匹配。由于 Postgres 允许函数重载，仅凭函数名并不能唯一标识要调用的函数——解析器必须根据所提供参数的数据类型选择正确的函数。
查询目标: SQL 的 INSERT 和 UPDATE 语句把表达式的结果放到表中。查询中的表达式必须与目标列的类型匹配，必要时还要转换成目标列的类型。
UNION 和 CASE 结构: 由于 UNION SELECT 语句的所有查询结果必须出现在一组列中，每个 SELECT 子句结果的类型必须匹配并转换成统一的集合。类似地，CASE 结构的结果表达式必须强制转换成公共类型，使 CASE 表达式整体有已知的输出类型。

许多一般类型转换规则使用了建立在 Postgres 函数和操作符系统表之上的简单约定。转换规则中还包含一些启发式规则，以便更好地支持 SQL92 标准固有类型（如 smallint、integer 和 float）的约定。

Postgres 解析器使用的约定是：所有类型转换函数都接受一个源类型的参数，并且以目标类型的名称命名。满足这些标准的任何函数都被认为是有效的转换函数，解析器可以把它当作转换函数使用。这个简单的假设使解析器无需硬编码就能探索类型转换的可能性，让扩展的用户定义类型透明地使用这些相同的特性。

解析器中还提供了一个额外的启发式规则，以便对 SQL 标准类型的正确行为做出更好的猜测。定义了几种基本的类型类别：boolean、 numeric、string、bitstring、datetime、timespan、geometric、network 以及用户自定义。除用户自定义外，每个类别都有一个在有歧义时会被优先选择的首选类型。在用户自定义类别中，每个类型都是自己的首选类型。有歧义的表达式（有多个候选解析解的表达式）在有多个可能的内置类型时通常可以解决，但在用户定义类型有多个选择时则会报错。

5.1.1. 指南

所有类型转换规则的设计都遵循若干原则：

隐式转换绝不应产生令人意外或无法预测的结果。
解析器没有先验知识的用户定义类型在类型层级中应该更“高”。在混合类型表达式中，固有类型总是应当转换成用户定义类型（当然，只在需要转换时如此）。
用户定义的类型之间没有关联。目前，Postgres 没有关于类型之间关系的信息，只有内置类型的硬编码启发式规则以及基于目录中可用函数的隐式关系。
如果查询不需要隐式类型转换，解析器或执行器就不应有额外的开销。也就是说，如果查询构造良好且类型已经匹配，查询就应当继续进行，不必在解析器上花费额外时间，也不必向查询中引入不必要的隐式转换函数。

此外，如果某个查询通常需要为函数做隐式转换，而之后用户用正确的参数类型定义了一个显式函数，解析器就应使用这个新函数，不再用旧函数做隐式转换。

上一页	上一级	下一页
4.12. 聚合函数	起始页	5.2. 操作符

提交更正

译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。

第 5 章 类型转换

5.1. 概述 #

5.1.1. 指南

提交更正

第 5 章类型转换