- the command type
This is a simple value telling which command
(SELECT, INSERT, UPDATE, DELETE) produced the parse tree.
- the range table
The range table is a list of relations that are used in the query.
In a SELECT statement these are the relations given after
the FROM keyword.
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
index rather than by name, so here it doesn't matter if there
are duplicate names as it would in an SQL
statement. This can happen after the range tables of rules
have been merged in. The examples in this document will not have
this situation.
- the result relation
This is an index into the range table that identifies the
relation where the results of the query go.
SELECT queries
normally don't have a result relation. The special case
of a SELECT INTO is mostly identical to a CREATE TABLE,
INSERT ... SELECT sequence and is not discussed separately
here.
On INSERT, UPDATE and DELETE queries the result relation
is the table (or view!) where the changes take effect.
- the target list
The target list is a list of expressions that define the result
of the query. In the case of a SELECT, the expressions are what
builds the final output of the query. They are the expressions
between the SELECT and the FROM keywords. (* is just an
abbreviation for all the attribute names of a relation. It is
expanded by the parser into the individual attributes, so the
rule system never sees it.)
DELETE queries don't need a target list because they don't
produce any result. In fact the planner will add a special CTID
entry to the empty target list. But this is after the rule
system and will be discussed later. For the rule system the
target list is empty.
In INSERT queries the target list describes the new rows that
should go into the result relation. It is the expressions in the VALUES
clause or the ones from the SELECT clause in INSERT ... SELECT.
The first step of the rewrite process adds target list entries
for any columns that were not assigned to by the original query
and 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.
In UPDATE queries, the target list describes the new rows that should
replace the old ones. In the rule system, it contains just the
expressions from the SET attribute = expression part of the query.
The planner will handle missing columns by inserting expressions that
copy the values from the old row into the new one. And it will add
the special CTID entry just as for DELETE too.
Every entry in the target list contains an expression that can
be a constant value, a variable pointing to an attribute of one
of the relations in the range table, a parameter, or an expression
tree made of function calls, constants, variables, operators etc.
- the qualification
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 if the operation
(INSERT, UPDATE, DELETE or SELECT) for the final result row should be
executed or not. It is the WHERE clause of an
SQL statement.
- the join tree
The query's join tree shows the structure of the FROM clause.
For a simple query like SELECT FROM a, b, c the join tree is just
a list of the FROM items, because we are allowed to join them in
any order. But when JOIN expressions --- particularly outer joins
--- are used, we have to join in the order shown by the joins.
The join tree shows the structure of the JOIN expressions. The
restrictions associated with particular JOIN clauses (from ON or
USING expressions) are stored as qualification expressions attached
to those join tree nodes. It turns out to be convenient to store
the top-level WHERE expression as a qualification attached to the
top-level join tree item, too. So really the join tree represents
both the FROM and WHERE clauses of a SELECT.
- the others
The other parts of the query tree like the ORDER BY
clause aren't of interest here. The rule system
substitutes entries there while applying rules, but that
doesn't have much to do with the fundamentals of the rule
system.
