writing these values
     as constants in an SQL command, you must put quotes around them,
     for example <literal>UPDATE table SET x = '-Infinity'</literal>.
     On input, these strings are recognized in a case-insensitive manner.
     The infinity values can alternatively be spelled <literal>inf</literal>
     and <literal>-inf</literal>.
    </para>

    <para>
     The infinity values behave as per mathematical expectations.  For
     example, <literal>Infinity</literal> plus any finite value equals
     <literal>Infinity</literal>, as does <literal>Infinity</literal>
     plus <literal>Infinity</literal>; but <literal>Infinity</literal>
     minus <literal>Infinity</literal> yields <literal>NaN</literal> (not a
     number), because it has no well-defined interpretation.  Note that an
     infinity can only be stored in an unconstrained <type>numeric</type>
     column, because it notionally exceeds any finite precision limit.
    </para>

    <para>
     The <literal>NaN</literal> (not a number) value is used to represent
     undefined calculational results.  In general, any operation with
     a <literal>NaN</literal> input yields another <literal>NaN</literal>.
     The only exception is when the operation's other inputs are such that
     the same output would be obtained if the <literal>NaN</literal> were to
     be replaced by any finite or infinite numeric value; then, that output
     value is used for <literal>NaN</literal> too.  (An example of this
     principle is that <literal>NaN</literal> raised to the zero power
     yields one.)
    </para>

    <note>
     <para>
      In most implementations of the <quote>not-a-number</quote> concept,
      <literal>NaN</literal> is not considered equal to any other numeric
      value (including <literal>NaN</literal>).  In order to allow
      <type>numeric</type> values to be sorted and used in tree-based
      indexes, <productname>PostgreSQL</productname> treats <literal>NaN</literal>
      values as equal, and greater than all non-<literal>NaN</literal>
      values.
     </para>
    </note>

    <para>
     The types <type>decimal</type> and <type>numeric</type> are
     equivalent.  Both types are part of the <acronym>SQL</acronym>
     standard.
    </para>

    <para>
     When rounding values, the <type>numeric</type> type rounds ties away
     from zero, while (on most machines) the <type>real</type>
     and <type>double precision</type> types round ties to the nearest even
     number.  For example:

<programlisting>
SELECT x,
  round(x::numeric) AS num_round,
  round(x::double precision) AS dbl_round
FROM generate_series(-3.5, 3.5, 1) as x;
  x   | num_round | dbl_round
------+-----------+-----------
 -3.5 |        -4 |        -4
 -2.5 |        -3 |        -2
 -1.5 |        -2 |        -2
 -0.5 |        -1 |        -0
  0.5 |         1 |         0
  1.5 |         2 |         2
  2.5 |         3 |         2
  3.5 |         4 |         4
(8 rows)
</programlisting>
    </para>
   </sect2>


   <sect2 id="datatype-float">
    <title>Floating-Point Types</title>

    <indexterm zone="datatype-float">
     <primary>real</primary>
    </indexterm>

    <indexterm zone="datatype-float">
     <primary>double precision</primary>
    </indexterm>

    <indexterm>
     <primary>float4</primary>
     <see>real</see>
    </indexterm>

    <indexterm>
     <primary>float8</primary>
     <see>double precision</see>
    </indexterm>

    <indexterm zone="datatype-float">
     <primary>floating point</primary>
    </indexterm>

    <para>
     The data types <type>real</type> and <type>double precision</type> are
     inexact, variable-precision numeric types. On all currently supported
     platforms, these types are implementations of <acronym>IEEE</acronym>
     Standard 754 for Binary Floating-Point Arithmetic (single and double
     precision, respectively), to the extent that the underlying processor,
     operating system, and compiler support it.
    </para>