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 remaining columns (with
        neither a given value nor a default) will be filled in by the
        planner with a constant null expression.
    </para>

    <para>
        For <command>UPDATE</command> commands, the target list
        describes the new rows that should replace the old ones. In the
        rule system, it contains just the expressions from the <literal>SET
        column = expression</literal> part of the command.  The planner will
        handle missing columns by inserting expressions that copy the values
        from the old row into the new one.  Just as for <command>DELETE</command>,
        a <acronym>CTID</acronym> or whole-row variable is added so that
        the executor can identify the old row to be updated.
    </para>

    <para>
        Every entry in the target list contains an expression that can
        be a constant value, a variable pointing to a column of one
        of the relations in the range table, a parameter, or an expression
        tree made of function calls, constants, variables, operators, etc.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        the qualification
    </term>
    <listitem>
    <para>
        The query's qualification is an expression much like one of
        those contained in the target list entries. The result value of
        this expression is a Boolean that tells whether the operation
        (<command>INSERT</command>, <command>UPDATE</command>,
        <command>DELETE</command>, or <command>SELECT</command>) for the
        final result row should be executed or not. It corresponds to the <literal>WHERE</literal> clause
        of an <acronym>SQL</acronym> statement.
    </para>
    </listitem>
    </varlistentry>

    <varlistentry>
    <term>
        the join tree
    </term>
    <listitem>
    <para>
        The query's join tree shows the structure of the <literal>FROM</literal> clause.
        For a simple query like <literal>SELECT ... FROM a, b, c</literal>, the join tree is just
        a list of the <literal>FROM</literal> items, because we are allowed to join them in
        any order.  But when <literal>JOIN</literal> expressions, particularly outer joins,
        are used, we have to join in the order shown by the joins.
        In that case, the join tree shows the structure of the <literal>JOIN</literal> expressions.  The
        restrictions associated with particular <literal>JOIN</literal> clauses (from <literal>ON</literal> or
        <literal>USING</literal> expressions) are stored as qualification expressions attached
        to those join-tree nodes.  It turns out to be convenient to store
        the top-level <literal>WHERE</literal> expression as a qualification attached to the
        top-level join-tree item, too.  So really the join tree represents
        both the <literal>FROM</literal> and <literal>WHERE</literal> clauses of a <command>SELECT</command>.
    </para>
    </listitem>
    </varlistentry>