Being slow or resource-hogging is not necessarily a bug. Read the
   documentation or ask on one of the mailing lists for help in tuning your
   applications. Failing to comply to the <acronym>SQL</acronym> standard is
   not necessarily a bug either, unless compliance for the
   specific feature is explicitly claimed.
  </para>

  <para>
   Before you continue, check on the TODO list and in the FAQ to see if your bug is
   already known. If you cannot decode the information on the TODO list, report your
   problem. The least we can do is make the TODO list clearer.
  </para>
 </sect2>

 <sect2 id="bug-reporting-what-to-report">
  <title>What to Report</title>

  <para>
   The most important thing to remember about bug reporting is to state all
   the facts and only facts. Do not speculate what you think went wrong, what
   <quote>it seemed to do</quote>, or which part of the program has a fault.
   If you are not familiar with the implementation you would probably guess
   wrong and not help us a bit. And even if you are, educated explanations are
   a great supplement to but no substitute for facts. If we are going to fix
   the bug we still have to see it happen for ourselves first.
   Reporting the bare facts
   is relatively straightforward (you can probably copy and paste them from the
   screen) but all too often important details are left out because someone
   thought it does not matter or the report would be understood
   anyway.
  </para>

  <para>
   The following items should be contained in every bug report:

   <itemizedlist>
    <listitem>
     <para>
      The exact sequence of steps <emphasis>from program
      start-up</emphasis> necessary to reproduce the problem. This
      should be self-contained; it is not enough to send in a bare
      <command>SELECT</command> statement without the preceding
      <command>CREATE TABLE</command> and <command>INSERT</command>
      statements, if the output should depend on the data in the
      tables. We do not have the time to reverse-engineer your
      database schema, and if we are supposed to make up our own data
      we would probably miss the problem.
     </para>

     <para>
      The best format for a test case for SQL-related problems is a
      file that can be run through the <application>psql</application>
      frontend that shows the problem. (Be sure to not have anything
      in your <filename>~/.psqlrc</filename> start-up file.)  An easy
      way to create this file is to use <application>pg_dump</application>
      to dump out the table declarations and data needed to set the
      scene, then add the problem query.  You are encouraged to
      minimize the size of your example, but this is not absolutely
      necessary.  If the bug is reproducible, we will find it either
      way.
     </para>

     <para>
      If your application uses some other client interface, such as <application>PHP</application>, then
      please try to isolate the offending queries. We will probably not set up a
      web server to reproduce your problem. In any case remember to provide
      the exact input files; do not guess that the problem happens for
      <quote>large files</quote> or <quote>midsize databases</quote>, etc. since this
      information is too inexact to be of use.
     </para>
    </listitem>

    <listitem>
     <para>
      The output you got. Please do not say that it <quote>didn't work</quote> or
      <quote>crashed</quote>. If there is an error message,
      show it, even if you do not understand it. If the program terminates with
      an operating system error, say which. If nothing at all happens, say so.
      Even if the result of your test case is a program crash or otherwise obvious
      it might not happen on our platform. The easiest thing is to copy the output
      from the terminal, if possible.
     </para>
     <note>
      <para>
       If you are reporting an error message, please obtain the most verbose
       form of