<productname>PostgreSQL</productname> should be considered.
 </para>

 <para>
  Conversely, as noted in the table there are some minor restrictions on
  the input format of JSON primitive types that do not apply to
  the corresponding <productname>PostgreSQL</productname> types.
 </para>

  <table id="json-type-mapping-table">
     <title>JSON Primitive Types and Corresponding <productname>PostgreSQL</productname> Types</title>
     <tgroup cols="3">
      <colspec colname="col1" colwidth="1*"/>
      <colspec colname="col2" colwidth="1*"/>
      <colspec colname="col3" colwidth="2*"/>
      <thead>
       <row>
        <entry>JSON primitive type</entry>
        <entry><productname>PostgreSQL</productname> type</entry>
        <entry>Notes</entry>
       </row>
      </thead>
      <tbody>
       <row>
        <entry><type>string</type></entry>
        <entry><type>text</type></entry>
        <entry><literal>\u0000</literal> is disallowed, as are Unicode escapes
         representing characters not available in the database encoding</entry>
       </row>
       <row>
        <entry><type>number</type></entry>
        <entry><type>numeric</type></entry>
        <entry><literal>NaN</literal> and <literal>infinity</literal> values are disallowed</entry>
       </row>
       <row>
        <entry><type>boolean</type></entry>
        <entry><type>boolean</type></entry>
        <entry>Only lowercase <literal>true</literal> and <literal>false</literal> spellings are accepted</entry>
       </row>
       <row>
        <entry><type>null</type></entry>
        <entry>(none)</entry>
        <entry>SQL <literal>NULL</literal> is a different concept</entry>
       </row>
      </tbody>
     </tgroup>
   </table>

 <sect2 id="json-keys-elements">
  <title>JSON Input and Output Syntax</title>
  <para>
   The input/output syntax for the JSON data types is as specified in
   <acronym>RFC</acronym> 7159.
  </para>
  <para>
   The following are all valid <type>json</type> (or <type>jsonb</type>) expressions:
<programlisting>
-- Simple scalar/primitive value
-- Primitive values can be numbers, quoted strings, true, false, or null
SELECT '5'::json;

-- Array of zero or more elements (elements need not be of same type)
SELECT '[1, 2, "foo", null]'::json;

-- Object containing pairs of keys and values
-- Note that object keys must always be quoted strings
SELECT '{"bar": "baz", "balance": 7.77, "active": false}'::json;

-- Arrays and objects can be nested arbitrarily
SELECT '{"foo": [true, "bar"], "tags": {"a": 1, "b": null}}'::json;
</programlisting>
  </para>

  <para>
   As previously stated, when a JSON value is input and then printed without
   any additional processing, <type>json</type> outputs the same text that was
   input, while <type>jsonb</type> does not preserve semantically-insignificant
   details such as whitespace.  For example, note the differences here:
<programlisting>
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)
</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,