声明不限定维数，数组值为何仍须保持各层形状一致

PostgreSQL 17的Arrays章节允许表的列保存变长多维数组，元素可以采用内置或用户定义的基础类型，也可以是枚举、复合、范围或domain类型。文档先说明元素是什么类型，再讨论数组怎样形成多层结构。一个数组类型名称中的方括号，因而不只是一张固定大小表格的简称。[1]

声明中可以写出具体大小，当前实现却忽略这类大小限制；声明的维数同样不被强制执行。原文进一步说，同一种元素类型的数组，不论大小或维数，都被视为相同类型。因此，声明里列出的长度与维数主要承担文档作用，并没有单凭这种写法限定之后所有值的运行时形状。[1]

这不等于具体数组值可以任意参差。Array Value Input一节明确要求，多维数组在每一维上具有匹配的范围。其整数例子用三个子数组构成三乘三的值；另一个日程例若一组有两个项目、另一组只有一个，就被文档列为格式不正确的数组值。这里检查的是这个值内部各层能否形成相符的形状，与是否强制声明尺寸不是同一件事。[1]

两项规则放在一起，能够解释看似相反的描述。声明没有把列锁成一个固定维数，不会自动取消多维值自身的结构要求；反过来，某个值呈现规则的两维形状，也不证明类型声明已经强制它只能如此。资料中可以分别记录声明写了什么，以及实际值的各层有哪些范围，而不让其中一份记录代替另一份。[1]

下标还有自己的起点。该版本默认采用从一开始的编号方式，但数组值也可以带有其他下界。输入输出说明用每一维的上下界表示这类范围，不能仅看到最上面的编号，就把它当作元素数量。下界属于位置编号的起点，维数描述有几层，某一维长度则描述这一层包含多少位置，三者各有用途。[1]

文档提供的几个名称把这些用途具体化。array_dims返回当前各维上下界的文本，array_lower和array_upper分别对应指定维的下界、上界，array_length则对应指定维长度。cardinality另外统计所有维度中的总元素数。在所列两维日程例里，一维长度为二，而总元素数为四；前者没有漏记另外两个元素，它本来就只回答某一维的问题。[1]

文本输出也保留了一项条件：只有至少一维的下界不是一时，输出才显式带上维度范围。因此，没有附出上下界的数组文字，并不能被读成“没有维度”。理解这段说明，需要连着默认起点与输出条件，而不是用显示得长短判断结构信息是否存在。[1]

本文只解释17版连续定义和纸面例子，未执行SQL或处理真实业务数据。网页新闻及版权日期不作为本节首次发表日。