pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
SQL 是一种强类型语言。也就是说，每个数据项 都有一个相关联的数据类型，它决定了该数据项的行为和允许的用法。 PostgreSQL 拥有一个可扩展的类型系统， 比其他 RDBMS 实现更加通用和灵活。 因此，PostgreSQL 中大部分类型转换行为 应当由一般规则而不是ad hoc（特定）启发式规则支配， 以使混合类型表达式即使在有用户定义类型时也有 意义。
PostgreSQL 的扫描器/解析器只把词法 元素解码成五种基本类别：整数、浮点数、字符串、 名字和关键字。大多数扩展类型首先被词法化为 字符串。SQL 语言定义允许用字符串指定类型 名，这一机制可以在 PostgreSQL 中用来让解析器走上正确的 路径。例如，查询
tgl=> SELECT text 'Origin' AS "Label", point '(0,0)' AS "Value"; Label | Value --------+------- Origin | (0,0) (1 row)
有两个字面常量，类型分别为 text 和 point。 如果没有为字符串字面量指定类型，则最初会赋予占位类型 unknown（未知），并在后面 阶段按如下所述解析。
在 PostgreSQL 解析器中有四种基本的 SQL 结构需要 专门的类型转换规则：
PostgreSQL 允许带前缀和后缀一元（单参数）操作符的 表达式， 也允许二元（双参数）操作符的 表达式。
PostgreSQL 类型系统的很大一部分是围绕一套 丰富的函数构建的。函数调用有一个或多个参数，对任何具体的 查询，这些参数都必须与系统 目录中可用的函数匹配。由于 PostgreSQL 允许函数 重载，仅凭函数名并不能唯一标识要调用的 函数；解析器必须根据所提供参数的数据 类型选择正确的函数。
SQL 的 INSERT 和 UPDATE 语句把表达式的 结果放到表中。查询中的表达式必须与目标列的 类型匹配，必要时还要转换成目标列的 类型。
UNION 和 CASE 结构由于联合起来的 SELECT 语句的所有查询结果必须出现在 一组列中，每个 SELECT 子句结果的类型 必须匹配并转换成统一的集合。 类似地，CASE 结构的结果表达式必须强制转换成 公共类型，使 CASE 表达式整体有已知的输出类型。
许多一般类型转换规则使用了建立在 PostgreSQL 函数和操作符系统表之上的简单约定。 转换规则中还包含一些启发式规则，以便更好地支持 SQL 标准固有类型（如 smallint、integer 和 real）的 约定。
PostgreSQL 解析器使用的约定是：所有 类型转换函数都接受一个源类型的参数，并且以 目标类型的名称命名。满足这些 标准的任何函数都被认为是有效的转换函数，解析器 可以把它当作转换函数使用。这个简单的假设使解析器 无需硬编码就能探索类型转换的可能性， 让扩展的用户定义类型透明地使用这些 相同的特性。
解析器中还提供了一个额外的启发式规则，以便对 SQL 标准类型的正确行为做出更好的猜测。定义了 几种基本的类型类别：boolean、 numeric、string、bitstring、datetime、timespan、geometric、network 以及用户自定义。除用户自定义外，每个类别都有一个 在有歧义时会被优先选择的首选类型。 在用户自定义类别中，每个类型都是自己的首选类型。 有歧义的表达式（有多个候选解析解的表达式） 在有多个可能的内置类型时通常可以解决，但在 用户定义类型有多个选择时则会 报错。
所有类型转换规则的设计都遵循若干原则：
隐式转换绝不应产生令人意外或无法预测的结果。
解析器没有关于用户定义类型的先验知识，这类类型在类型层次结构中应当处于“更高”的位置。在混合类型的表达式中，原生类型应当总是被转换为用户定义类型（当然，仅在确有必要转换时）。
用户定义的类型之间没有关联。目前，PostgreSQL 没有关于类型之间关系的信息，只有内置类型的硬编码 启发式规则以及基于目录中可用函数的 隐式关系。
如果查询不需要隐式类型转换，解析器或执行器就不应 有额外的开销。 也就是说，如果查询构造良好且类型已经匹配，查询就应当 继续进行，不必在解析器上花费额外时间，也不必向查询中 引入不必要的隐式转换 函数。
此外，如果某个查询通常需要为函数做隐式转换，而 之后用户用正确的参数类型定义了一个显式函数，解析器 就应使用这个新函数，不再用旧函数做 隐式转换。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。