statement is broken into when it is in the query tree
    structure. The parts of a query tree are

<variablelist>
    <varlistentry>
    <term>
        the command type
    </term>
    <listitem>
    <para>
        This is a simple value telling which command
        (<command>SELECT</command>, <command>INSERT</command>,
        <command>UPDATE</command>, <command>DELETE</command>) produced
        the query tree.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        the range table
      <indexterm><primary>range table</primary></indexterm>
    </term>
    <listitem>
    <para>
        The range table is a list of relations that are used in the query.
        In a <command>SELECT</command> statement these are the relations given after
        the <literal>FROM</literal> key word.
    </para>

    <para>
        Every range table entry identifies a table or view and tells
        by which name it is called in the other parts of the query.
        In the query tree, the range table entries are referenced by
        number rather than by name, so here it doesn't matter if there
        are duplicate names as it would in an <acronym>SQL</acronym>
        statement. This can happen after the range tables of rules
        have been merged in. The examples in this chapter will not have
        this situation.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        the result relation
    </term>
    <listitem>
    <para>
        This is an index into the range table that identifies the
        relation where the results of the query go.
    </para>

    <para>
        <command>SELECT</command> queries don't have a result
        relation. (The special case of <command>SELECT INTO</command> is
        mostly identical to <command>CREATE TABLE</command> followed by
        <literal>INSERT ... SELECT</literal>, and is not discussed
        separately here.)
    </para>

    <para>
        For <command>INSERT</command>, <command>UPDATE</command>, and
        <command>DELETE</command> commands, the result relation is the table
        (or view!) where the changes are to take effect.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        the target list
    <indexterm><primary>target list</primary></indexterm>
    </term>
    <listitem>
    <para>
        The target list is a list of expressions that define the
        result of the query.  In the case of a
        <command>SELECT</command>, these expressions are the ones that
        build the final output of the query.  They correspond to the
        expressions between the key words <command>SELECT</command>
        and <command>FROM</command>.  (<literal>*</literal> is just an
        abbreviation for all the column names of a relation.  It is
        expanded by the parser into the individual columns, so the
        rule system never sees it.)
    </para>

    <para>
        <command>DELETE</command> commands don't need a normal target list
        because they don't produce any result.  Instead, the planner
        adds a special <acronym>CTID</acronym> entry to the empty target list,
        to allow the executor to find the row to be deleted.
        (<acronym>CTID</acronym> is added when the result relation is an ordinary
        table.  If it is a view, a whole-row variable is added instead, by
        the rule system, as described in <xref linkend="rules-views-update"/>.)
    </para>

    <para>
        For <command>INSERT</command> commands, the target list describes
        the new rows that should go into the result relation. It consists of the
        expressions in the <literal>VALUES</literal> clause or the ones from the
        <command>SELECT</command> clause in <literal>INSERT
        ... SELECT</literal>.  The first step of the rewrite process adds
        target list entries for any columns that were not assigned to by
        the original command but have defaults.  Any