</programlisting>
  </para>

  <para>
   On the other hand, the following query finds all the cities that
   are not state capitals and are situated at an elevation over 500 feet:

<programlisting>
SELECT name, elevation
    FROM ONLY cities
    WHERE elevation &gt; 500;

   name    | elevation
-----------+-----------
 Las Vegas |      2174
 Mariposa  |      1953
</programlisting>
  </para>

  <para>
   Here the <literal>ONLY</literal> keyword indicates that the query
   should apply only to <structname>cities</structname>, and not any tables
   below <structname>cities</structname> in the inheritance hierarchy.  Many
   of the commands that we have already discussed &mdash;
   <command>SELECT</command>, <command>UPDATE</command> and
   <command>DELETE</command> &mdash; support the
   <literal>ONLY</literal> keyword.
  </para>

  <para>
   You can also write the table name with a trailing <literal>*</literal>
   to explicitly specify that descendant tables are included:

<programlisting>
SELECT name, elevation
    FROM cities*
    WHERE elevation &gt; 500;
</programlisting>

   Writing <literal>*</literal> is not necessary, since this behavior is always
   the default.  However, this syntax is still supported for
   compatibility with older releases where the default could be changed.
  </para>

  <para>
   In some cases you might wish to know which table a particular row
   originated from. There is a system column called
   <structfield>tableoid</structfield> in each table which can tell you the
   originating table:

<programlisting>
SELECT c.tableoid, c.name, c.elevation
FROM cities c
WHERE c.elevation &gt; 500;
</programlisting>

   which returns:

<programlisting>
 tableoid |   name    | elevation
----------+-----------+-----------
   139793 | Las Vegas |      2174
   139793 | Mariposa  |      1953
   139798 | Madison   |       845
</programlisting>

   (If you try to reproduce this example, you will probably get
   different numeric OIDs.)  By doing a join with
   <structname>pg_class</structname> you can see the actual table names:

<programlisting>
SELECT p.relname, c.name, c.elevation
FROM cities c, pg_class p
WHERE c.elevation &gt; 500 AND c.tableoid = p.oid;
</programlisting>

   which returns:

<programlisting>
 relname  |   name    | elevation
----------+-----------+-----------
 cities   | Las Vegas |      2174
 cities   | Mariposa  |      1953
 capitals | Madison   |       845
</programlisting>
  </para>

  <para>
   Another way to get the same effect is to use the <type>regclass</type>
   alias type, which will print the table OID symbolically:

<programlisting>
SELECT c.tableoid::regclass, c.name, c.elevation
FROM cities c
WHERE c.elevation &gt; 500;
</programlisting>
  </para>

  <para>
   Inheritance does not automatically propagate data from
   <command>INSERT</command> or <command>COPY</command> commands to
   other tables in the inheritance hierarchy. In our example, the
   following <command>INSERT</command> statement will fail:
<programlisting>
INSERT INTO cities (name, population, elevation, state)
VALUES ('Albany', NULL, NULL, 'NY');
</programlisting>
   We might hope that the data would somehow be routed to the
   <structname>capitals</structname> table, but this does not happen:
   <command>INSERT</command> always inserts into exactly the table
   specified.  In some cases it is possible to redirect the insertion
   using a rule (see <xref linkend="rules"/>).  However that does not
   help for the above case because the <structname>cities</structname> table
   does not contain the column <structfield>state</structfield>, and so the
   command will be rejected before the rule can be applied.
  </para>

  <para>
   All check constraints and not-null constraints on a parent table are
   automatically inherited by its children, unless explicitly specified
   otherwise with <literal>NO INHERIT</literal> clauses.  Other types of constraints
   (unique, primary key, and foreign key constraints) are not inherited.