<entry><literal>5(+-)0.3</literal></entry>
      <entry>
        Creates an interval <literal>4.7 .. 5.3</literal>.
        Note that the <literal>(+-)</literal> notation isn't preserved.
      </entry>
     </row>
     <row>
      <entry><literal>50 .. </literal></entry>
      <entry>Everything that is greater than or equal to 50</entry>
     </row>
     <row>
      <entry><literal>.. 0</literal></entry>
      <entry>Everything that is less than or equal to 0</entry>
     </row>
     <row>
      <entry><literal>1.5e-2 .. 2E-2 </literal></entry>
      <entry>Creates an interval <literal>0.015 .. 0.02</literal></entry>
     </row>
     <row>
      <entry><literal>1 ... 2</literal></entry>
      <entry>
       The same as <literal>1...2</literal>, or <literal>1 .. 2</literal>,
       or <literal>1..2</literal>
       (spaces around the range operator are ignored)
      </entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   Because the <literal>...</literal> operator is widely used in data sources, it is allowed
   as an alternative spelling of the <literal>..</literal> operator.  Unfortunately, this
   creates a parsing ambiguity: it is not clear whether the upper bound
   in <literal>0...23</literal> is meant to be <literal>23</literal> or <literal>0.23</literal>.
   This is resolved by requiring at least one digit before the decimal
   point in all numbers in <type>seg</type> input.
  </para>

  <para>
   As a sanity check, <type>seg</type> rejects intervals with the lower bound
   greater than the upper, for example <literal>5 .. 2</literal>.
  </para>

 </sect2>

 <sect2 id="seg-precision">
  <title>Precision</title>

  <para>
   <type>seg</type> values are stored internally as pairs of 32-bit floating point
   numbers. This means that numbers with more than 7 significant digits
   will be truncated.
  </para>

  <para>
   Numbers with 7 or fewer significant digits retain their
   original precision. That is, if your query returns 0.00, you will be
   sure that the trailing zeroes are not the artifacts of formatting: they
   reflect the precision of the original data. The number of leading
   zeroes does not affect precision: the value 0.0067 is considered to
   have just 2 significant digits.
  </para>
 </sect2>

 <sect2 id="seg-usage">
  <title>Usage</title>

  <para>
   The <filename>seg</filename> module includes a GiST index operator class for
   <type>seg</type> values.
   The operators supported by the GiST operator class are shown in <xref linkend="seg-gist-operators"/>.
  </para>

  <table id="seg-gist-operators">
   <title>Seg GiST Operators</title>
    <tgroup cols="1">
     <thead>
      <row>
       <entry role="func_table_entry"><para role="func_signature">
        Operator
       </para>
       <para>
        Description
       </para></entry>
      </row>
     </thead>

     <tbody>
      <row>
       <entry role="func_table_entry"><para role="func_signature">
        <type>seg</type> <literal>&lt;&lt;</literal> <type>seg</type>
        <returnvalue>boolean</returnvalue>
       </para>
       <para>
        Is the first <type>seg</type> entirely to the left of the second?
        [a, b] &lt;&lt; [c, d] is true if b &lt; c.
       </para></entry>
      </row>

      <row>
       <entry role="func_table_entry"><para role="func_signature">
        <type>seg</type> <literal>&gt;&gt;</literal> <type>seg</type>
        <returnvalue>boolean</returnvalue>
       </para>
       <para>
        Is the first <type>seg</type> entirely to the right of the second?
        [a, b] &gt;&gt; [c, d] is true if a &gt; d.
       </para></entry>
      </row>

      <row>
       <entry role="func_table_entry"><para role="func_signature">
        <type>seg</type> <literal>&amp;&lt;</literal> <type>seg</type>
        <returnvalue>boolean</returnvalue>
       </para>
       <para>
        Does the first