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)
</programlisting>
   One semantically-insignificant detail worth noting is that
   in <type>jsonb</type>, numbers will be printed according to the behavior of the
   underlying <type>numeric</type> type.  In practice this means that numbers
   entered with <literal>E</literal> notation will be printed without it, for
   example:
<programlisting>
SELECT '{"reading": 1.230e-5}'::json, '{"reading": 1.230e-5}'::jsonb;
         json          |          jsonb
-----------------------+-------------------------
 {"reading": 1.230e-5} | {"reading": 0.00001230}
(1 row)
</programlisting>
   However, <type>jsonb</type> will preserve trailing fractional zeroes, as seen
   in this example, even though those are semantically insignificant for
   purposes such as equality checks.
  </para>

  <para>
    For the list of built-in functions and operators available for
    constructing and processing JSON values, see <xref linkend="functions-json"/>.
  </para>
 </sect2>

 <sect2 id="json-doc-design">
  <title>Designing JSON Documents</title>
  <para>
   Representing data as JSON can be considerably more flexible than
   the traditional relational data model, which is compelling in
   environments where requirements are fluid.  It is quite possible
   for both approaches to co-exist and complement each other within
   the same application.  However, even for applications where maximal
   flexibility is desired, it is still recommended that JSON documents
   have a somewhat fixed structure.  The structure is typically
   unenforced (though enforcing some business rules declaratively is
   possible), but having a predictable structure makes it easier to write
   queries that usefully summarize a set of <quote>documents</quote> (datums)
   in a table.
  </para>
  <para>
   JSON data is subject to the same concurrency-control
   considerations as any other data type when stored in a table.
   Although storing large documents is practicable, keep in mind that
   any update acquires a row-level lock on the whole row.
   Consider limiting JSON documents to a
   manageable size in order to decrease lock contention among updating
   transactions.  Ideally, JSON documents should each
   represent an atomic datum that business rules dictate cannot
   reasonably be further subdivided into smaller datums that
   could be modified independently.
  </para>
 </sect2>

 <sect2 id="json-containment">
  <title><type>jsonb</type> Containment and Existence</title>
  <indexterm>
    <primary>jsonb</primary>
    <secondary>containment</secondary>
  </indexterm>
  <indexterm>
    <primary>jsonb</primary>
    <secondary>existence</secondary>
  </indexterm>
  <para>
    Testing <firstterm>containment</firstterm> is an important capability of
    <type>jsonb</type>.  There is no parallel set of facilities for the
    <type>json</type> type.  Containment tests whether
    one <type>jsonb</type> document has contained within it another one.
    These examples return true except as noted:
  </para>
<programlisting>
-- Simple scalar/primitive values contain only the identical value:
SELECT '"foo"'::jsonb @&gt; '"foo"'::jsonb;

-- The array on the right side is contained within the one on the left:
SELECT '[1, 2, 3]'::jsonb @&gt; '[1, 3]'::jsonb;

-- Order of array elements is not significant, so this is also true:
SELECT '[1, 2, 3]'::jsonb @&gt; '[3, 1]'::jsonb;

-- Duplicate array elements don't matter either:
SELECT '[1, 2, 3]'::jsonb @&gt; '[1, 2, 2]'::jsonb;

-- The object with a single pair on the right side is contained
-- within the object on the left side:
SELECT '{"product": "PostgreSQL", "version": 9.4, "jsonb": true}'::jsonb @&gt; '{"version": 9.4}'::jsonb;