left of the decimal point exceeds the declared precision minus the
     declared scale, an error is raised.
     For example, a column declared as
<programlisting>
NUMERIC(3, 1)
</programlisting>
     will round values to 1 decimal place and can store values between
     -99.9 and 99.9, inclusive.
    </para>

    <para>
     Beginning in <productname>PostgreSQL</productname> 15, it is allowed
     to declare a <type>numeric</type> column with a negative scale.  Then
     values will be rounded to the left of the decimal point.  The
     precision still represents the maximum number of non-rounded digits.
     Thus, a column declared as
<programlisting>
NUMERIC(2, -3)
</programlisting>
     will round values to the nearest thousand and can store values
     between -99000 and 99000, inclusive.
     It is also allowed to declare a scale larger than the declared
     precision.  Such a column can only hold fractional values, and it
     requires the number of zero digits just to the right of the decimal
     point to be at least the declared scale minus the declared precision.
     For example, a column declared as
<programlisting>
NUMERIC(3, 5)
</programlisting>
     will round values to 5 decimal places and can store values between
     -0.00999 and 0.00999, inclusive.
    </para>

    <note>
     <para>
      <productname>PostgreSQL</productname> permits the scale in a
      <type>numeric</type> type declaration to be any value in the range
      -1000 to 1000.  However, the <acronym>SQL</acronym> standard requires
      the scale to be in the range 0 to <replaceable>precision</replaceable>.
      Using scales outside that range may not be portable to other database
      systems.
     </para>
    </note>

    <para>
     Numeric values are physically stored without any extra leading or
     trailing zeroes.  Thus, the declared precision and scale of a column
     are maximums, not fixed allocations.  (In this sense the <type>numeric</type>
     type is more akin to <type>varchar(<replaceable>n</replaceable>)</type>
     than to <type>char(<replaceable>n</replaceable>)</type>.)  The actual storage
     requirement is two bytes for each group of four decimal digits,
     plus three to eight bytes overhead.
    </para>

    <indexterm>
     <primary>infinity</primary>
     <secondary>numeric (data type)</secondary>
    </indexterm>

    <indexterm>
     <primary>NaN</primary>
     <see>not a number</see>
   </indexterm>

    <indexterm>
     <primary>not a number</primary>
     <secondary>numeric (data type)</secondary>
    </indexterm>

    <para>
     In addition to ordinary numeric values, the <type>numeric</type> type
     has several special values:
<literallayout>
<literal>Infinity</literal>
<literal>-Infinity</literal>
<literal>NaN</literal>
</literallayout>
     These are adapted from the IEEE 754 standard, and represent
     <quote>infinity</quote>, <quote>negative infinity</quote>, and
     <quote>not-a-number</quote>, respectively. When 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>