一般来说，JSON数据应该存储为jsonb数据类型，除非特殊需要，例如关于对象键顺序的遗留假设。

json数据类型的输入和输出语法如RFC 7159中所述。

下列都是合法的json表达式：

-- 简单标量/原始值
-- 原始值值可以是数字、带引号的字符串、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数据类型，将根据基础数字类型的行为打印数字。在实践中，这意味着使用e符号输入的数字将不使用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比传统关系数据模型要更灵活，在需求变化的环境中表现得尤其明显。在同一个应用中很可能两种方法会共存并且成为彼此的互补。不过，即便是对于要求最大灵活性的应用中，我们仍然推荐JSON有些许固定的结构。这种结构是非强制的（尽管可能会强制一些业务规则），但是如果有可预测的结构会让编写有效汇总表中一组“文档”（数据）的查询更容易。

在表中存储时，JSON数据服从和其他任何数据类型一样的并发控制考虑。尽管存储大型文档格式可行的，但要记住任何更新都要求整个行上的一个行级锁。为了降低更新事务之间的锁竞争，请考虑限制JSON文档为一个可管理的尺寸。理想上，每个JSON文档应该表示业务规则规定的一个原子数据，并且不能进一步地被分解为更小的可以独立修改的数据。

测试容器是jsonb的一项重要功能。 json类型没有并行的设施集。容器测试一个jsonb 文档中是否包含了另一个jsonb 文档。这些例子返回true，除非另有标注：

--简单标量/原始数值仅包含相同的值：
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": "Greenplum", "version": "6.0.0", "jsonb":true}'::jsonb @> '{"version":"6.0.0"}'::jsonb;

--右侧的数组被认为不包含在左侧的数组中，即使其中嵌套了类似的数组：
SELECT '[1, 2, [1, 3]]'::jsonb @> '[1, 3]'::jsonb;  -- yields false

--但是，通过一层嵌套，它包含：
SELECT '[1, 2, [1, 3]]'::jsonb @> '[[1, 3]]'::jsonb;

--同样，此处未报告遏制：
SELECT '{"foo": {"bar": "baz", "zig": "zag"}}'::jsonb @> '{"bar": "baz"}'::jsonb; -- yields false

-- 但是，通过一层嵌套，它包含：
SELECT '{"foo": {"bar": "baz", "zig": "zag"}}'::jsonb @> '{"foo": {"bar": "baz"}}'::jsonb;

一般原则是，所包含的对象必须在结构和数据内容方面与包含的对象匹配，可能是在从包含的对象中丢弃一些不匹配的数组元素或对象键/值对之后。 对于容器，在进行容器匹配时，数组元素的顺序并不重要，重复的数组元素只被有效地考虑一次。

作为结构必须匹配的一般原则的例外，数组可以包含原始值：

-- 此数组包含原始字符串值：:
SELECT '["foo", "bar"]'::jsonb @> '"bar"'::jsonb;

-- 这个异常不是相互的——这里报告了非包容：:
SELECT '"bar"'::jsonb @> '["bar"]'::jsonb;  -- yields false

jsonb 还有一个existence操作符，它是容器主题的变体：它测试字符串（作为文本值给出）是否作为对象键或数组元素出现在jsonb 值的顶层。这些示例返回true，，除非另有标注：

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

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

-- 不考虑对象值：
SELECT '{"foo": "bar"}'::jsonb ? 'bar';  -- yields false

-- 与容器一样，存在必须在顶层匹配：
SELECT '{"foo": {"bar": "baz"}}'::jsonb ? 'bar'; -- yields false

-- 如果字符串与原始JSON字符串匹配，则认为该字符串存在：
SELECT '"foo"'::jsonb ? 'foo';

当涉及到许多键或元素时，JSON对象比数组更适合测试包含性或存在性，因为与数组不同，JSON对象在内部针对搜索进行了优化，不需要进行线性搜索。

各种容器和存在操作符以及所有其他JSON操作符和函数都记录在JSON函数和操作符JSON函数和操作符中。

因为JSON容器是嵌套的，所以适当的查询可以跳过子对象的显式选择。例如，假设我们有一个包含顶级对象的doc列，其中大多数对象包含子对象数组的标记字段。此查询查找包含"term":"paris"和"term":"food"的子对象出现的条目，同时忽略标记数组之外的任何此类键：

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"}]';

然而，第二种方法的灵活性较低，而且效率通常也较低。

另一方面，json存在操作符不是嵌套的：它只在json值的顶层查找指定的键或数组元素。