~ubuntu-branches/ubuntu/karmic/postgresql-8.4/karmic-security

 <para>

  The previous chapters explained how to create tables, how to fill

  them with data, and how to manipulate that data.  Now we finally

 </para>

 

 

 </para>

 

 <para>

  table expression: it reads just one table.  In general, table

  expressions can be complex constructs of base tables, joins, and

  subqueries.  But you can also omit the table expression entirely and

 

   <para>

    When a table reference names a table that is the parent of a

    key word <literal>ONLY</> precedes the table name.  However, the

    reference produces only the columns that appear in the named table

    &mdash; any columns added in subtables are ignored.

</synopsis>

 

       <para>

        <replaceable>T1</replaceable> and

        the tables have N and M rows respectively, the joined

        table will have N * M rows.

       </para>

        comma-separated list of column names, which the joined tables

        must have in common, and forms a join condition specifying

        equality of each of these pairs of columns.  Furthermore, the

        other columns from each table.  Thus, <literal>USING (a, b,

        c)</literal> is equivalent to <literal>ON (t1.a = t2.a AND

        t1.b = t2.b AND t1.c = t2.c)</literal> with the exception that

        if <literal>ON</> is used there will be two columns

        <literal>a</>, <literal>b</>, and <literal>c</> in the result,

       </para>

 

       <para>

        </indexterm>

        Finally, <literal>NATURAL</> is a shorthand form of

        <literal>USING</>: it forms a <literal>USING</> list

        input tables.  As with <literal>USING</>, these columns appear

        only once in the output table.

       </para>

          <para>

           First, an inner join is performed.  Then, for each row in

           T1 that does not satisfy the join condition with any row in

           one row for each row in T1.

          </para>

         </listitem>

          <para>

           First, an inner join is performed.  Then, for each row in

           T2 that does not satisfy the join condition with any row in

           T1.  This is the converse of a left join: the result table

          </para>

         </listitem>

        </varlistentry>

          <para>

           First, an inner join is performed.  Then, for each row in

           T1 that does not satisfy the join condition with any row in

           T2.  Also, for each row of T2 that does not satisfy the

           values in the columns of T1 is added.

          </para>

         </listitem>

 

    <para>

     Joins of all types can be chained together or nested: either or

     can be used around <literal>JOIN</> clauses to control the join

     order.  In the absence of parentheses, <literal>JOIN</> clauses

     nest left-to-right.

   3 | c    |     |

(3 rows)

</screen>

    </para>

   </sect3>

 

SELECT * FROM my_table AS m WHERE my_table.a &gt; 5;

</programlisting>

     is not valid according to the SQL standard.  In

     <xref linkend="guc-add-missing-from"> configuration variable is

     <literal>off</> (as it is by default).  If it is <literal>on</>,

     an implicit table reference will be added to the

 

    <para>

     When an alias is applied to the output of a <literal>JOIN</>

<programlisting>

SELECT a.* FROM my_table AS a JOIN your_table AS b ON ...

</programlisting>

<programlisting>

SELECT a.* FROM (my_table AS a JOIN your_table AS b ON ...) AS c

</programlisting>

     outside the alias <literal>c</>.

    </para>

   </sect3>

 

    <para>

     If a table function returns a base data type, the single result

     composite type, the result columns get the same names as the

     individual attributes of the type.

    </para>

SELECT * FROM getfoo(1) AS t1;

 

SELECT * FROM foo

 

CREATE VIEW vw_getfoo AS SELECT * FROM getfoo(1);

 

     In some cases it is useful to define table functions that can

     return different column sets depending on how they are invoked.

     To support this, the table function can be declared as returning

     a query, the expected row structure must be specified in the

     query itself, so that the system can know how to parse and plan

     the query.  Consider this example:

<programlisting>

SELECT *

      AS t1(proname name, prosrc text)

    WHERE proname LIKE 'bytea%';

</programlisting>

    After the processing of the <literal>FROM</> clause is done, each

    row of the derived virtual table is checked against the search

    condition.  If the result of the condition is true, the row is

    false or null) it is discarded.  The search condition typically

    <literal>FROM</> clause; this is not required, but otherwise the

    <literal>WHERE</> clause will be fairly useless.

   </para>

</programlisting>

     Which one of these you use is mainly a matter of style.  The

     <literal>JOIN</> syntax in the <literal>FROM</> clause is

     clause of an outer join is <emphasis>not</> equivalent to a

     of rows (for unmatched input rows) as well as the removal of rows

     from the final result.

    </para>

 

SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 &gt; fdt.c1)

</programlisting>

    <literal>FROM</> clause. Rows that do not meet the search

    condition of the <literal>WHERE</> clause are eliminated from

    <literal>fdt</literal>. Notice the use of scalar subqueries as

 

   <para>

    The <xref linkend="sql-groupby" endterm="sql-groupby-title"> is

    values in all the columns listed. The order in which the columns

    are listed does not matter.  The effect is to combine each set

    eliminate redundancy in the output and/or compute aggregates that

    apply to these groups.  For instance:

<screen>

 

   <para>

    In general, if a table is grouped, columns that are not

    expressions.  An example with aggregate expressions is:

<screen>

<prompt>=&gt;</> <userinput>SELECT x, sum(y) FROM test1 GROUP BY x;</>

   <tip>

    <para>

     Grouping without aggregate expressions effectively calculates the

     using the <literal>DISTINCT</> clause (see <xref

     linkend="queries-distinct">).

    </para>

 

   <para>

    Here is another example:  it calculates the total sales for each

<programlisting>

SELECT product_id, p.name, (sum(s.units) * p.price) AS sales

    FROM products p LEFT JOIN sales s USING (product_id)

    In this example, the columns <literal>product_id</literal>,

    <literal>p.name</literal>, and <literal>p.price</literal> must be

    in the <literal>GROUP BY</> clause since they are referenced in

    table is set up, name and price might be fully dependent on the

    product ID, so the additional groupings could theoretically be

    <literal>s.units</> does not have to be in the <literal>GROUP

    BY</> list since it is only used in an aggregate expression

    (<literal>sum(...)</literal>), which represents the sales

   </indexterm>

 

   <para>

    <literal>HAVING</literal> clause can be used, much like a

<synopsis>

SELECT <replaceable>select_list</replaceable> FROM ... <optional>WHERE ...</optional> GROUP BY ... HAVING <replaceable>boolean_expression</replaceable>

</synopsis>

    the row's values substituted for any column references.  But the

    expressions in the select list do not have to reference any

    columns in the table expression of the <literal>FROM</> clause;

   </para>

  </sect2>

 

 

   <para>

    The entries in the select list can be assigned names for further

<programlisting>

SELECT a AS value, b + c AS sum FROM ...

</programlisting>

    <para>

     The naming of output columns here is different from that done in

     the <literal>FROM</> clause (see <xref

     the select list is the one that will be passed on.

    </para>

   </note>

    The <literal>DISTINCT ON</> clause is not part of the SQL standard

    and is sometimes considered bad style because of the potentially

    indeterminate nature of its results.  With judicious use of

    construct can be avoided, but it is often the most convenient

    alternative.

   </para>

<synopsis>

<replaceable>query1</replaceable> UNION <replaceable>query2</replaceable> UNION <replaceable>query3</replaceable>

</synopsis>

<synopsis>

(<replaceable>query1</replaceable> UNION <replaceable>query2</replaceable>) UNION <replaceable>query3</replaceable>

</synopsis>

  <para>

   The <literal>NULLS FIRST</> and <literal>NULLS LAST</> options can be

   used to determine whether nulls appear before or after non-null values

  </para>

 

  <para>

  </para>

 

  <para>

   of an output column, as in:

<programlisting>

SELECT a + b AS sum, c FROM table1 ORDER BY sum;

SELECT a, max(b) FROM table1 GROUP BY a ORDER BY 1;

</programlisting>

   both of which sort by the first output column.  Note that an output

   &mdash; for example, this is <emphasis>not</> correct:

<programlisting>

SELECT a + b AS sum, c FROM table1 ORDER BY sum + c;          -- wrong

 

  <para>

   When using <literal>LIMIT</>, it is important to use an

   unique order.  Otherwise you will get an unpredictable subset of

   the query's rows. You might be asking for the tenth through

   ordering is unknown, unless you specified <literal>ORDER BY</>.

  </para>

 

  <para>

   The query optimizer takes <literal>LIMIT</> into account when

   plans (yielding different row orders) depending on what you give

   for <literal>LIMIT</> and <literal>OFFSET</>.  Thus, using

   different <literal>LIMIT</>/<literal>OFFSET</> values to select

<synopsis>

VALUES ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) [, ...]

</synopsis>

   The lists must all have the same number of elements (i.e., the number

   of columns in the table), and corresponding entries in each list must

   have compatible data types.  The actual data type assigned to each column

 

  <para>

   Syntactically, <literal>VALUES</> followed by expression lists is

<synopsis>

SELECT <replaceable>select_list</replaceable> FROM <replaceable>table_expression</replaceable>

</synopsis>

   and can appear anywhere a <literal>SELECT</> can.  For example, you can

   <replaceable>sort_specification</replaceable> (<literal>ORDER BY</>,

   <literal>LIMIT</>, and/or <literal>OFFSET</>) to it.  <literal>VALUES</>

   is most commonly used as the data source in an <command>INSERT</> command,