RFC 7159 中定义了 JSON 数据类型的输入/输出语法。

下列都是合法的json（或者jsonb）表达式：

-- 简单标量/基本值
-- 基本值可以是数字、带引号的字符串、true、false或者null
SELECT '5'::json;

-- 有零个或者更多元素的数组（元素不需要为同一类型）
SELECT '[1, 2, "foo", null]'::json;

-- 包含键值对的对象
-- 注意对象键必须总是带引号的字符串
SELECT '{"bar": "baz", "balance": 7.77, "active": false}'::json;

-- 数组和对象可以被任意嵌套
SELECT '{"foo": [true, "bar"], "tags": {"a": 1, "b": null}}'::json;

如前所述，当输入一个JSON值并且没有进行额外处理时，json输出与输入相同的文本，而jsonb不保留语义上无关紧要的细节，如空格。例如，请注意这里的差异：

SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::json;
                      json
-------------------------------------------------
 {"bar": "baz", "balance": 7.77, "active":false}
(1 row)

SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::jsonb;
                      jsonb
--------------------------------------------------
 {"bar": "baz", "active": false, "balance": 7.77}
(1 row)

一个值得注意的语义上无关紧要的细节是，在jsonb中，数字将根据底层的numeric类型的行为进行打印。实际上，这意味着使用E表示法输入的数字将被打印为没有该表示法，例如：

SELECT '{"reading": 1.230e-5}'::json, '{"reading": 1.230e-5}'::jsonb;
         json          |          jsonb
-----------------------+-------------------------
 {"reading": 1.230e-5} | {"reading": 0.00001230}
(1 row)

然而，jsonb将保留尾部的小数零，如这个例子所示，即使对于诸如相等性检查之类的目的，这些零在语义上是无关紧要的。

对于可用于构造和处理 JSON 值的内置函数和运算符的列表，参见 第 9.16 节。

将数据表示为 JSON 比传统关系数据模型要灵活得多，在需求不固定时 这种优势更加令人感兴趣。在同一个应用里非常有可能有两种方法共存 并且互补。不过，即便是在要求最大灵活性的应用中，我们还是推荐 JSON 文档有固定的结构。该结构通常是非强制的（尽管可能会强制一 些业务规则），但是有一个可预测的结构会使书写概括一个表中的 “文档”（数据）集合的查询更容易。

当被存储在表中时，JSON 数据也像其他数据类型一样服从相同的并发 控制考虑。尽管存储大型文档是可行的，但是要记住任何更新都在整行 上要求一个行级锁。为了在更新事务之间减少锁争夺，可考虑把 JSON 文档限制到一个可管理的尺寸。理想情况下，JSON 文档应该每个表示 一个原子数据，业务规则命令不会进一步把它们划分成更小的可独立修 改的数据。

测试包含是jsonb的一种重要能力。对 json类型没有平行的功能集。包含测试会测试一个 jsonb文档是否被包含在另一个文档中。除了特别注解 之外，这些例子都会返回真：

-- 简单的标量/基本值只包含相同的值：
SELECT '"foo"'::jsonb @> '"foo"'::jsonb;

-- 右边的数字被包含在左边的数组中：
SELECT '[1, 2, 3]'::jsonb @> '[1, 3]'::jsonb;

-- 数组元素的顺序没有意义，因此这个例子也返回真：
SELECT '[1, 2, 3]'::jsonb @> '[3, 1]'::jsonb;

-- 重复的数组元素也没有关系：
SELECT '[1, 2, 3]'::jsonb @> '[1, 2, 2]'::jsonb;

-- 右边具有一个单一键值对的对象被包含在左边的对象中：
SELECT '{"product": "PostgreSQL", "version": 9.4, "jsonb": true}'::jsonb @> '{"version": 9.4}'::jsonb;

-- 右边的数组不会被认为包含在左边的数组中，
-- 即使其中嵌入了一个相似的数组：
SELECT '[1, 2, [1, 3]]'::jsonb @> '[1, 3]'::jsonb;  -- 得到假

-- 但是如果同样也有嵌套，包含就成立：
SELECT '[1, 2, [1, 3]]'::jsonb @> '[[1, 3]]'::jsonb;

-- 类似的，这个例子也不会被认为是包含：
SELECT '{"foo": {"bar": "baz"}}'::jsonb @> '{"bar": "baz"}'::jsonb;  -- 得到假

-- 包含一个顶层键和一个空对象：
SELECT '{"foo": {"bar": "baz"}}'::jsonb @> '{"foo": {}}'::jsonb;

一般原则是被包含的对象必须在结构和数据内容上匹配包含对象，这种匹配 可以是从包含对象中丢弃了不匹配的数组元素或者对象键值对之后成立。但 是记住做包含匹配时数组元素的顺序是没有意义的，并且重复的数组元素实 际也只会考虑一次。

结构必须匹配的一般原则有一种特殊情况，一个数组可以包含一个基本值：

-- 这个数组包含基本字符串值：
SELECT '["foo", "bar"]'::jsonb @> '"bar"'::jsonb;

-- 反之不然，下面的例子会报告“不包含”：
SELECT '"bar"'::jsonb @> '["bar"]'::jsonb;  -- 得到假

jsonb还有一个存在操作符，它是包含的一种 变体：它测试一个字符串（以一个text值的形式给出）是否出 现在jsonb值顶层的一个对象键或者数组元素中。除非特别注解， 下面这些例子返回真：

-- 字符串作为一个数组元素存在：
SELECT '["foo", "bar", "baz"]'::jsonb ? 'bar';

-- 字符串作为一个对象键存在：
SELECT '{"foo": "bar"}'::jsonb ? 'foo';

-- 不考虑对象值：
SELECT '{"foo": "bar"}'::jsonb ? 'bar';  -- 得到假

-- 和包含一样，存在必须在顶层匹配：
SELECT '{"foo": {"bar": "baz"}}'::jsonb ? 'bar'; -- 得到假

-- 如果一个字符串匹配一个基本 JSON 字符串，它就被认为存在：
SELECT '"foo"'::jsonb ? 'foo';

当涉及很多键或元素时，JSON 对象比数组更适合于做包含或存在测试， 因为它们不像数组，进行搜索时会进行内部优化，并且不需要被线性搜索。

SELECT doc->'site_name' FROM websites
  WHERE doc @> '{"tags":[{"term":"paris"}, {"term":"food"}]}';

SELECT doc->'site_name' FROM websites
  WHERE doc->'tags' @> '[{"term":"paris"}, {"term":"food"}]';

第 9.16 节中记录了多个包含和存在操作符，以及 所有其他 JSON 操作符和函数。

GIN 索引可以被用来有效地搜索在大量jsonb文档（数据）中出现 的键或者键值对。提供了两种 GIN “操作符类”，它们在性能和灵活 性方面做出了不同的平衡。

默认的jsonb GIN操作符类支持使用键存在操作符?、?|和?&、包含操作符@>，以及jsonpath匹配操作符@?和@@。 （有关这些操作符实现的语义细节，请参见表 9.46。） 使用此操作符类创建索引的示例为：

CREATE INDEX idxgin ON api USING GIN (jdoc);

非默认的GIN操作符类jsonb_path_ops不支持键存在操作符，但支持@>、@?和@@。 使用此操作符类创建索引的示例为：

CREATE INDEX idxginp ON api USING GIN (jdoc jsonb_path_ops);

考虑这样一个例子：一个表存储了从一个第三方 Web 服务检索到的 JSON 文档，并且有一个模式定义。一个典型的文档：

{
    "guid": "9c36adc1-7fb5-4d5b-83b4-90356a46061a",
    "name": "Angela Barton",
    "is_active": true,
    "company": "Magnafone",
    "address": "178 Howard Place, Gulf, Washington, 702",
    "registered": "2009-11-07T08:53:22 +08:00",
    "latitude": 19.793713,
    "longitude": 86.513373,
    "tags": [
        "enim",
        "aliquip",
        "qui"
    ]
}

我们把这些文档存储在一个名为api的表的名为 jdoc的jsonb列中。如果在这个列上创建一个 GIN 索引，下面这样的查询就能利用该索引：

-- 寻找键 "company" 有值 "Magnafone" 的文档
SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"company": "Magnafone"}';

不过，该索引不能被用于下面这样的查询，因为尽管操作符? 是可索引的，但它不能直接被应用于被索引列jdoc：

-- 寻找这样的文档：其中的键 "tags" 包含键或数组元素 "qui"
SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc -> 'tags' ? 'qui';

但是，通过适当地使用表达式索引，上述查询也能使用一个索引。 如果对"tags"键中的特定项的查询很常见，可能值得 定义一个这样的索引：

CREATE INDEX idxgintags ON api USING gin ((jdoc -> 'tags'));

现在，WHERE 子句 jdoc -> 'tags' ? 'qui' 将被识别为可索引操作符?在索引表达式jdoc -> 'tags' 上的应用（更多有关表达式索引的信息可见第 11.7 节）。

另一种查询的方法是利用包含，例如：

-- 寻找这样的文档：其中键 "tags" 包含数组元素 "qui"
SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qui"]}';

jdoc列上的一个简单 GIN 索引就能支持这个查询。 但是注意这样一个索引将会存储jdoc列中每一个键 和值的拷贝，然而前一个例子的表达式索引只存储tags 键下找到的数据。虽然简单索引的方法更加灵活（因为它支持有关任 意键的查询），定向的表达式索引更小并且搜索速度比简单索引更快。

GIN索引还支持@?和@@操作符，执行jsonpath匹配。示例为

SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @? '$.tags[*] ? (@ == "qui")';

SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';

对于这些操作符，GIN索引从jsonpath模式中提取形如 accessors_chain = constant的子句，并基于这些子句中提到的键和值进行索引搜索。访问器链 可能包括.key、 [*]和 [index]访问器。 jsonb_ops操作符类还支持.*和.**访问器， 但jsonb_path_ops操作符类不支持。

尽管jsonb_path_ops操作符类仅支持使用@>、 @?和@@操作符的查询，但与默认操作符类 jsonb_ops相比，它具有显著的性能优势。通常，jsonb_path_ops 索引比相同数据上的jsonb_ops索引要小得多，并且搜索的特异性更好， 特别是当查询包含在数据中频繁出现的键时。因此，搜索操作通常比使用默认操作符类时性能更好。

jsonb_ops和jsonb_path_ops GIN 索引之间的技术区别是前者为数据中的每一个键和值创建独立的索引项， 而后者值为该数据中的每个值创建索引项。 ^[7] 基本上，每一个jsonb_path_ops索引项是其所对应的值和 键的哈希。例如要索引{"foo": {"bar": "baz"}}，将创建一个 单一的索引项，它把所有三个foo、bar、 和baz合并到哈希值中。因此一个查找这个结构的包含查询可能 导致极度详细的索引搜索。但是根本没有办法找到foo是否作为 一个键出现。在另一方面，一个jsonb_ops会创建三个索引 项分别表示foo、bar和baz。那么要 做同样的包含查询，它将会查找包含所有三个项的行。虽然 GIN 索引能够相当 有效地执行这种 AND 搜索，它仍然不如等效的 jsonb_path_ops搜索那样详细和快速（特别是如果有大量 行包含三个索引项中的任意一个时）。

jsonb_path_ops方法的一个不足是它不会为不包含任何值 的 JSON 结构创建索引项，例如{"a": {}}。如果需要搜索包 含这样一种结构的文档，它将要求一次全索引扫描，那就非常慢。 因此jsonb_path_ops不适合经常执行这类搜索的应用。

jsonb也支持btree和hash索引。 这通常值用于检查完整 JSON 文档等值非常重要的场合。jsonb 数据的btree顺序很少有人关系，但是为了完整性其顺序是：

对象 > 数组 > 布尔 > 数字 > 字符串 > 空值

带有 n 对的对象 > 带有 n - 1 对的对象

带有 n 个元素的数组 > 带有 n - 1 个元素的数组

具有相同数量对的对象这样比较：

key-1, value-1, key-2 ...

注意对象键被按照它们的存储顺序进行比较，特别是由于较短的键被存储在 较长的键之前，这可能导致结果不直观，例如：

{ "aa": 1, "c": 1} > {"b": 1, "d": 1}

相似地，具有相同元素数量的数组按照以下顺序比较：

element-1, element-2 ...

基本 JSON 值的比较会使用低层PostgreSQL 数据类型相同的比较规则进行。字符串的比较会使用默认的数据库排序规则。

jsonb 数据类型支持用于检索和修改元素的数组样式索引。 嵌套值与 jsonb_set 函数中path参数规则相同，可以被链式下标表达式指定。如果jsonb 类型的值是一个数组，数值下标从零开始，负整数从数组的最后的元素倒数。 不支持切片表达式。下标表达式的结果始终是 jsonb 数据类型。

UPDATE 语句或许在 SET 子句中使用下标来修改 jsonb 值。下标路径必须对它存在范围内的所有受影响的值都是可遍历的。 例如，val,val['a'],和 val['a']['b']如果每个路径都是一个对象， 则val['a']['b']['c']路径可以一直被遍历访问到 c， 如果 val['a'] 或者 val['a']['b'] 中任何一个没有定义， 将创建为空对象并根据需要进行填充。 但是， 如果 val 本身或者其中任何一个中间值被定义为非对象， 例如 字符串， 数字，或者jsonb null等，将无法访问并发生错误，事务将中止。

下面是下标语法的一个示例：

-- 通过键提取对象值
SELECT ('{"a": 1}'::jsonb)['a'];

-- 通过键路径提取嵌套对象值
SELECT ('{"a": {"b": {"c": 1}}}'::jsonb)['a']['b']['c'];

-- 通过索引提取数组元素
SELECT ('[1, "2", null]'::jsonb)[1];

-- 通过键更新对象值。注意'1'周围的引号：分配的值也必须是jsonb类型
UPDATE table_name SET jsonb_field['key'] = '1';

-- 如果任何记录的jsonb_field['a']['b']不是对象，则会引发错误。例如，值{"a": 1}具有键'a'的数值。
UPDATE table_name SET jsonb_field['a']['b']['c'] = '1';

-- 使用下标的WHERE子句过滤记录。由于下标的结果是jsonb，我们比较的值也必须是jsonb。双引号使"value"也成为有效的jsonb字符串。
SELECT * FROM table_name WHERE jsonb_field['key'] = '"value"';

通过下标赋值jsonb处理一些边缘情况与jsonb_set不同。当源jsonb值为NULL时，通过下标赋值将继续进行，就好像它是由下标键隐含的类型（对象或数组）的空JSON值：

-- 其中jsonb_field为NULL，现在是{"a": 1}
UPDATE table_name SET jsonb_field['a'] = '1';

-- 其中jsonb_field为NULL，现在是[1]
UPDATE table_name SET jsonb_field[0] = '1';

如果为包含太少元素的数组指定了索引，将附加NULL元素，直到达到索引并且可以设置值。

-- 其中jsonb_field为[]，现在是[null, null, 2];
-- 其中jsonb_field为[0]，现在是[0, null, 2]
UPDATE table_name SET jsonb_field[2] = '2';

只要要遍历的最后一个现有元素是对象或数组（由相应的下标隐含），jsonb值将接受对不存在的下标路径的赋值，直到可以放置分配的值为止，将创建嵌套的数组和对象结构，在前一种情况下，根据下标路径填充null。

-- 其中jsonb_field为{}，现在是{"a": [{"b": 1}]}
UPDATE table_name SET jsonb_field['a'][0]['b'] = '1';

-- 其中jsonb_field为[]，现在是[null, {"a": 1}]
UPDATE table_name SET jsonb_field[1]['a'] = '1';

有一些附加的扩展可以为不同的过程语言实现jsonb类型的转换。

PL/Perl的扩展被称作jsonb_plperl和jsonb_plperlu。如果使用它们，jsonb值会视情况被映射为Perl的数组、哈希和标量。

PL/Python的扩展名为jsonb_plpython3u。 如果您使用它，jsonb值将被映射到Python字典、列表和标量，适当地。

在这些扩展中，jsonb_plperl被认为是“trusted”， 也就是说，它可以由对当前数据库具有CREATE权限的非超级用户安装。 其余的需要超级用户权限才能安装。

在PostgreSQL中，jsonpath类型实现支持SQL/JSON 路径语言以有效地查询 JSON 数据。 它提供了已解析的SQL/JSON路径表达式的二进制表示，该表达式指定路径引擎从JSON数据中检索的项，以便使用SQL/JSON查询函数进行进一步处理。

SQL/JSON 路径谓词和运算符的语义通常遵循 SQL。同时，为了提供使用 JSON 数据的自然方法，SQL/JSON 路径语法使用一些 JavaScript 约定：

SQL/JSON路径表达式通常在SQL查询中以SQL字符串文字的形式编写，因此必须用单引号括起， 并且值中所需的任何单引号必须加倍（参见第 4.1.2.1 节）。 某些形式的路径表达式需要其中的字符串文字。 这些嵌入式字符串文字遵循JavaScript/ECMAScript约定： 它们必须用双引号括起，并且可以在其中使用反斜杠转义来表示其他难以输入的字符。 特别是，在嵌入式字符串文字中写入双引号的方法是\"， 而要写入反斜杠本身，必须写为\\。其他特殊的反斜杠序列 包括JavaScript字符串中识别的那些： \b、 \f、 \n、 \r、 \t、 \v 用于各种ASCII控制字符， \xNN表示用仅两个十六进制数字编写的字符代码， \uNNNN表示由其4个十六进制代码点标识的Unicode字符， 以及\u{N...}表示用1至6个十六进制数字编写的Unicode字符代码点。

路径表达式由一系列路径元素组成，可以是以下任何一种：

有关使用jsonpath具有 SQL/JSON 查询函数的表达式的详细信息，参见第 9.16.2 节。