|
Server : Apache/2.2.2 (Fedora) System : Linux App1.pathumtani.go.th 2.6.20-1.2320.fc5smp #1 SMP Tue Jun 12 19:40:16 EDT 2007 i686 User : apache ( 48) PHP Version : 5.2.9 Disable Function : NONE Directory : /proc/self/root/usr/share/doc/postgresql-8.1.9/html/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Inheritance</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 8.1.9 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Data Definition"
HREF="ddl.html"><LINK
REL="PREVIOUS"
TITLE="Schemas"
HREF="ddl-schemas.html"><LINK
REL="NEXT"
TITLE="Partitioning"
HREF="ddl-partitioning.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2007-04-20T04:40:08"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
>PostgreSQL 8.1.9 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="ddl-schemas.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="ddl.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 5. Data Definition</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="ddl.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="ddl-partitioning.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="DDL-INHERIT"
>5.8. Inheritance</A
></H1
><A
NAME="AEN2535"
></A
><A
NAME="AEN2537"
></A
><P
> <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> implements table inheritance
which can be a useful tool for database designers. (SQL:1999 and
later define a type inheritance feature, which differs in many
respects from the features described here.)
</P
><P
> Let's start with an example: suppose we are trying to build a data
model for cities. Each state has many cities, but only one
capital. We want to be able to quickly retrieve the capital city
for any particular state. This can be done by creating two tables,
one for state capitals and one for cities that are not
capitals. However, what happens when we want to ask for data about
a city, regardless of whether it is a capital or not? The
inheritance feature can help to resolve this problem. We define the
<TT
CLASS="STRUCTNAME"
>capitals</TT
> table so that it inherits from
<TT
CLASS="STRUCTNAME"
>cities</TT
>:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE TABLE cities (
name text,
population float,
altitude int -- in feet
);
CREATE TABLE capitals (
state char(2)
) INHERITS (cities);</PRE
><P>
In this case, the <TT
CLASS="STRUCTNAME"
>capitals</TT
> table <I
CLASS="FIRSTTERM"
>inherits</I
>
all the columns of its parent table, <TT
CLASS="STRUCTNAME"
>cities</TT
>. State
capitals also have an extra column, <TT
CLASS="STRUCTFIELD"
>state</TT
>, that shows
their state.
</P
><P
> In <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>, a table can inherit from
zero or more other tables, and a query can reference either all
rows of a table or all rows of a table plus all of its descendant tables.
The latter behavior is the default.
For example, the following query finds the names of all cities,
including state capitals, that are located at an altitude over
500ft:
</P><PRE
CLASS="PROGRAMLISTING"
>SELECT name, altitude
FROM cities
WHERE altitude > 500;</PRE
><P>
Given the sample data from the <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>
tutorial (see <A
HREF="tutorial-sql.html#TUTORIAL-SQL-INTRO"
>Section 2.1</A
>), this returns:
</P><PRE
CLASS="PROGRAMLISTING"
> name | altitude
-----------+----------
Las Vegas | 2174
Mariposa | 1953
Madison | 845</PRE
><P>
</P
><P
> On the other hand, the following query finds all the cities that
are not state capitals and are situated at an altitude over 500ft:
</P><PRE
CLASS="PROGRAMLISTING"
>SELECT name, altitude
FROM ONLY cities
WHERE altitude > 500;
name | altitude
-----------+----------
Las Vegas | 2174
Mariposa | 1953</PRE
><P>
</P
><P
> Here the <TT
CLASS="LITERAL"
>ONLY</TT
> keyword indicates that the query
should apply only to <TT
CLASS="STRUCTNAME"
>cities</TT
>, and not any tables
below <TT
CLASS="STRUCTNAME"
>cities</TT
> in the inheritance hierarchy. Many
of the commands that we have already discussed —
<TT
CLASS="COMMAND"
>SELECT</TT
>, <TT
CLASS="COMMAND"
>UPDATE</TT
> and
<TT
CLASS="COMMAND"
>DELETE</TT
> — support the
<TT
CLASS="LITERAL"
>ONLY</TT
> keyword.
</P
><P
> In some cases you may wish to know which table a particular row
originated from. There is a system column called
<TT
CLASS="STRUCTFIELD"
>tableoid</TT
> in each table which can tell you the
originating table:
</P><PRE
CLASS="PROGRAMLISTING"
>SELECT c.tableoid, c.name, c.altitude
FROM cities c
WHERE c.altitude > 500;</PRE
><P>
which returns:
</P><PRE
CLASS="PROGRAMLISTING"
> tableoid | name | altitude
----------+-----------+----------
139793 | Las Vegas | 2174
139793 | Mariposa | 1953
139798 | Madison | 845</PRE
><P>
(If you try to reproduce this example, you will probably get
different numeric OIDs.) By doing a join with
<TT
CLASS="STRUCTNAME"
>pg_class</TT
> you can see the actual table names:
</P><PRE
CLASS="PROGRAMLISTING"
>SELECT p.relname, c.name, c.altitude
FROM cities c, pg_class p
WHERE c.altitude > 500 and c.tableoid = p.oid;</PRE
><P>
which returns:
</P><PRE
CLASS="PROGRAMLISTING"
> relname | name | altitude
----------+-----------+----------
cities | Las Vegas | 2174
cities | Mariposa | 1953
capitals | Madison | 845</PRE
><P>
</P
><P
> Inheritance does not automatically propagate data from
<TT
CLASS="COMMAND"
>INSERT</TT
> or <TT
CLASS="COMMAND"
>COPY</TT
> commands to
other tables in the inheritance hierarchy. In our example, the
following <TT
CLASS="COMMAND"
>INSERT</TT
> statement will fail:
</P><PRE
CLASS="PROGRAMLISTING"
>INSERT INTO cities (name, population, altitude, state)
VALUES ('New York', NULL, NULL, 'NY');</PRE
><P>
We might hope that the data would somehow be routed to the
<TT
CLASS="STRUCTNAME"
>capitals</TT
> table, but this does not happen:
<TT
CLASS="COMMAND"
>INSERT</TT
> always inserts into exactly the table
specified. In some cases it is possible to redirect the insertion
using a rule (see <A
HREF="rules.html"
>Chapter 34</A
>). However that does not
help for the above case because the <TT
CLASS="STRUCTNAME"
>cities</TT
> table
does not contain the column <TT
CLASS="STRUCTFIELD"
>state</TT
>, and so the
command will be rejected before the rule can be applied.
</P
><P
> Check constraints can be defined on tables within an inheritance
hierarchy. All check constraints on a parent table are
automatically inherited by all of its children. Other types of
constraints are not inherited, however.
</P
><P
> A table can inherit from more than one parent table, in which case it has
the union of the columns defined by the parent tables. Any columns
declared in the child table's definition are added to these. If the
same column name appears in multiple parent tables, or in both a parent
table and the child's definition, then these columns are <SPAN
CLASS="QUOTE"
>"merged"</SPAN
>
so that there is only one such column in the child table. To be merged,
columns must have the same data types, else an error is raised. The
merged column will have copies of all the check constraints coming from
any one of the column definitions it came from.
</P
><P
> Table inheritance can currently only be defined using the <A
HREF="sql-createtable.html"
><I
>CREATE TABLE</I
></A
>
statement. The related statement <TT
CLASS="COMMAND"
>CREATE TABLE AS</TT
> does
not allow inheritance to be specified. There
is no way to add an inheritance link to make an existing table into
a child table. Similarly, there is no way to remove an inheritance
link from a child table once it has been defined, other than by dropping
the table completely. A parent table cannot be dropped
while any of its children remain. If you wish to remove a table and
all of its descendants, one easy way is to drop the parent table with
the <TT
CLASS="LITERAL"
>CASCADE</TT
> option.
</P
><P
> <A
HREF="sql-altertable.html"
><I
>ALTER TABLE</I
></A
> will
propagate any changes in column data definitions and check
constraints down the inheritance hierarchy. Again, dropping
columns or constraints on parent tables is only possible when using
the <TT
CLASS="LITERAL"
>CASCADE</TT
> option. <TT
CLASS="COMMAND"
>ALTER
TABLE</TT
> follows the same rules for duplicate column merging
and rejection that apply during <TT
CLASS="COMMAND"
>CREATE TABLE</TT
>.
</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="DDL-INHERIT-CAVEATS"
>5.8.1. Caveats</A
></H2
><P
> Table access permissions are not automatically inherited. Therefore,
a user attempting to access a parent table must either have permissions
to do the operation on all its child tables as well, or must use the
<TT
CLASS="LITERAL"
>ONLY</TT
> notation. When adding a new child table to
an existing inheritance hierarchy, be careful to grant all the needed
permissions on it.
</P
><P
> A serious limitation of the inheritance feature is that indexes (including
unique constraints) and foreign key constraints only apply to single
tables, not to their inheritance children. This is true on both the
referencing and referenced sides of a foreign key constraint. Thus,
in the terms of the above example:
<P
></P
></P><UL
><LI
><P
> If we declared <TT
CLASS="STRUCTNAME"
>cities</TT
>.<TT
CLASS="STRUCTFIELD"
>name</TT
> to be
<TT
CLASS="LITERAL"
>UNIQUE</TT
> or a <TT
CLASS="LITERAL"
>PRIMARY KEY</TT
>, this would not stop the
<TT
CLASS="STRUCTNAME"
>capitals</TT
> table from having rows with names duplicating
rows in <TT
CLASS="STRUCTNAME"
>cities</TT
>. And those duplicate rows would by
default show up in queries from <TT
CLASS="STRUCTNAME"
>cities</TT
>. In fact, by
default <TT
CLASS="STRUCTNAME"
>capitals</TT
> would have no unique constraint at all,
and so could contain multiple rows with the same name.
You could add a unique constraint to <TT
CLASS="STRUCTNAME"
>capitals</TT
>, but this
would not prevent duplication compared to <TT
CLASS="STRUCTNAME"
>cities</TT
>.
</P
></LI
><LI
><P
> Similarly, if we were to specify that
<TT
CLASS="STRUCTNAME"
>cities</TT
>.<TT
CLASS="STRUCTFIELD"
>name</TT
> <TT
CLASS="LITERAL"
>REFERENCES</TT
> some
other table, this constraint would not automatically propagate to
<TT
CLASS="STRUCTNAME"
>capitals</TT
>. In this case you could work around it by
manually adding the same <TT
CLASS="LITERAL"
>REFERENCES</TT
> constraint to
<TT
CLASS="STRUCTNAME"
>capitals</TT
>.
</P
></LI
><LI
><P
> Specifying that another table's column <TT
CLASS="LITERAL"
>REFERENCES
cities(name)</TT
> would allow the other table to contain city names, but
not capital names. There is no good workaround for this case.
</P
></LI
></UL
><P>
These deficiencies will probably be fixed in some future release,
but in the meantime considerable care is needed in deciding whether
inheritance is useful for your problem.
</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Deprecated: </B
> In previous versions of <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>, the
default behavior was not to include child tables in queries. This was
found to be error prone and is also in violation of the SQL
standard. Under the old syntax, to include the child tables you append
<TT
CLASS="LITERAL"
>*</TT
> to the table name. For example:
</P><PRE
CLASS="PROGRAMLISTING"
>SELECT * from cities*;</PRE
><P>
You can still explicitly specify scanning child tables by
appending <TT
CLASS="LITERAL"
>*</TT
>, as well as explicitly specify not
scanning child tables by writing <TT
CLASS="LITERAL"
>ONLY</TT
>. But
beginning in version 7.1, the default behavior for an undecorated
table name is to scan its child tables too, whereas before the
default was not to do so. To get the old default behavior,
disable the <A
HREF="runtime-config-compatible.html#GUC-SQL-INHERITANCE"
>sql_inheritance</A
> configuration
option.
</P
></BLOCKQUOTE
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="ddl-schemas.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="ddl-partitioning.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Schemas</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ddl.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Partitioning</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>