think it looks OK and is exactly what we expected. We should not have to      spend the time to decode the exact semantics behind your commands.      Especially refrain from merely saying that <quote>This is not what SQL says/Oracle      does.</quote> Digging out the correct behavior from <acronym>SQL</acronym>      is not a fun undertaking, nor do we all know how all the other relational      databases out there behave. (If your problem is a program crash, you can      obviously omit this item.)     </para>    </listitem>    <listitem>     <para>      Any command line options and other start-up options, including      any relevant environment variables or configuration files that      you changed from the default. Again, please provide exact      information. If you are using a prepackaged distribution that      starts the database server at boot time, you should try to find      out how that is done.     </para>    </listitem>    <listitem>     <para>      Anything you did at all differently from the installation      instructions.     </para>    </listitem>    <listitem>     <para>      The <productname>PostgreSQL</productname> version. You can run the command      <literal>SELECT version();</literal> to      find out the version of the server you are connected to.  Most executable      programs also support a <option>--version</option> option; at least      <literal>postmaster --version</literal> and <literal>psql --version</literal>      should work.      If the function or the options do not exist then your version is      more than old enough to warrant an upgrade.      If you run a prepackaged version, such as RPMs, say so, including any      subversion the package may have. If you are talking about a CVS      snapshot, mention that, including its date and time.     </para>     <para>      If your version is older than &version; we will almost certainly      tell you to upgrade. There are many bug fixes and improvements      in each new release, so it is quite possible that a bug you have      encountered in an older release of <productname>PostgreSQL</>      has already been fixed. We can only provide limited support for      sites using older releases of <productname>PostgreSQL</>; if you      require more than we can provide, consider acquiring a      commercial support contract.     </para>     <para>     </para>    </listitem>    <listitem>     <para>      Platform information. This includes the kernel name and version,      C library, processor, memory information, and so on. In most      cases it is sufficient to report the vendor and version, but do      not assume everyone knows what exactly <quote>Debian</quote>      contains or that everyone runs on Pentiums. If you have      installation problems then information about the toolchain on      your machine (compiler, <application>make</application>, and so      on) is also necessary.     </para>    </listitem>   </itemizedlist>   Do not be afraid if your bug report becomes rather lengthy. That is a fact of life.   It is better to report everything the first time than us having to squeeze the   facts out of you. On the other hand, if your input files are huge, it is   fair to ask first whether somebody is interested in looking into it.  Here is   an <ulink url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">article</ulink>   that outlines some more tips on reporting bugs.  </para>  <para>   Do not spend all your time to figure out which changes in the input make   the problem go away. This will probably not help solving it. If it turns   out that the bug cannot be fixed right away, you will still have time to   find and share your work-around. Also, once again, do not waste your time   guessing why the bug exists. We will find that out soon enough.  </para>  <para>   When writing a bug report, please avoid confusing terminology.   The software package in total is called <quote>PostgreSQL</quote>,   sometimes <quote>Postgres</quote> for short. If you   are specifically talking about the backend server, mention that, do not   just say <quote>PostgreSQL crashes</quote>.  A crash of a single   backend server process is quite different from crash of the parent   <quote>postmaster</> process; please don't say <quote>the postmaster   crashed</> when you mean a single backend process went down, nor vice versa.   Also, client programs such as the interactive frontend <quote><application>psql</application></quote>   are completely separate from the backend.  Please try to be specific   about whether the problem is on the client or server side.  </para> </sect2> <sect2>  <title>Where to report bugs</title>  <para>   In general, send bug reports to the bug report mailing list at   <email>pgsql-bugs@postgresql.org</email>.   You are requested to use a descriptive subject for your email   message, perhaps parts of the error message.  </para>  <para>    Another method is to fill in the bug report web-form available   at the project's   <ulink url="http://www.postgresql.org/">web site</ulink>.   Entering a bug report this way causes it to be mailed to the   <email>pgsql-bugs@postgresql.org</email> mailing list.  </para>  <para>   If your bug report has security implications and you'd prefer that it   not become immediately visible in public archives, don't send it to   <literal>pgsql-bugs</literal>.  Security issues can be   reported privately to <email>security@postgresql.org</email>.  </para>  <para>    Do not send bug reports to any of the user mailing lists, such as   <email>pgsql-sql@postgresql.org</email> or   <email>pgsql-general@postgresql.org</email>.   These mailing lists are for answering   user questions, and their subscribers normally do not wish to receive   bug reports. More importantly, they are unlikely to fix them.  </para>  <para>   Also, please do <emphasis>not</emphasis> send reports to   the developers' mailing list <email>pgsql-hackers@postgresql.org</email>.   This list is for discussing the   development of <productname>PostgreSQL</productname>, and it would be nice   if we could keep the bug reports separate. We might choose to take up a   discussion about your bug report on <literal>pgsql-hackers</literal>,   if the problem needs more review.  </para>  <para>   If you have a problem with the documentation, the best place to report it   is the documentation mailing list <email>pgsql-docs@postgresql.org</email>.   Please be specific about what part of the documentation you are unhappy   with.  </para>   <para>   If your bug is a portability problem on a non-supported platform,   send mail to <email>pgsql-ports@postgresql.org</email>,   so we (and you) can work on   porting <productname>PostgreSQL</productname> to your platform.  </para>  <note>   <para>    Due to the unfortunate amount of spam going around, all of the above    email addresses are closed mailing lists. That is, you need to be    subscribed to a list to be allowed to post on it.  (You need not be    subscribed to use the bug-report web form, however.)    If you would like to send mail but do not want to receive list traffic,    you can subscribe and set your subscription option to <literal>nomail</>.    For more information send mail to    <email>majordomo@postgresql.org</email>    with the single word <literal>help</> in the body of the message.   </para>  </note> </sect2></sect1><!-- Keep this comment at the end of the fileLocal variables:mode:sgmlsgml-omittag:nilsgml-shorttag:tsgml-minimize-attributes:nilsgml-always-quote-attributes:tsgml-indent-step:1sgml-indent-data:tsgml-parent-document:nilsgml-default-dtd-file:"./reference.ced"sgml-exposed-tags:nilsgml-local-catalogs:("/usr/lib/sgml/catalog")sgml-local-ecat-files:nilEnd:-->