This page in other versions: 9.0 / 9.1 / 9.2 / 9.3 / 9.4  |  Development versions: devel  |  Unsupported versions: 7.3 / 7.4 / 8.0 / 8.1 / 8.2 / 8.3 / 8.4

5.8. Inheritance

PostgreSQL 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.)

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 capitals table so that it inherits from cities:

CREATE TABLE cities (
    name            text,
    population      float,
    altitude        int     -- in feet
);

CREATE TABLE capitals (
    state           char(2)
) INHERITS (cities);

In this case, the capitals table inherits all the columns of its parent table, cities. State capitals also have an extra column, state, that shows their state.

In PostgreSQL, 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:

SELECT name, altitude
    FROM cities
    WHERE altitude > 500;

Given the sample data from the PostgreSQL tutorial (see Section 2.1), this returns:

   name    | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
 Madison   |      845

On the other hand, the following query finds all the cities that are not state capitals and are situated at an altitude over 500ft:

SELECT name, altitude
    FROM ONLY cities
    WHERE altitude > 500;

   name    | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953

Here the ONLY keyword indicates that the query should apply only to cities, and not any tables below cities in the inheritance hierarchy. Many of the commands that we have already discussed — SELECT, UPDATE and DELETE — support the ONLY keyword.

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

SELECT c.tableoid, c.name, c.altitude
FROM cities c
WHERE c.altitude > 500;

which returns:

 tableoid |   name    | altitude
----------+-----------+----------
   139793 | Las Vegas |     2174
   139793 | Mariposa  |     1953
   139798 | Madison   |      845

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

SELECT p.relname, c.name, c.altitude
FROM cities c, pg_class p
WHERE c.altitude > 500 and c.tableoid = p.oid;

which returns:

 relname  |   name    | altitude
----------+-----------+----------
 cities   | Las Vegas |     2174
 cities   | Mariposa  |     1953
 capitals | Madison   |      845

Inheritance does not automatically propagate data from INSERT or COPY commands to other tables in the inheritance hierarchy. In our example, the following INSERT statement will fail:

INSERT INTO cities (name, population, altitude, state)
VALUES ('New York', NULL, NULL, 'NY');

We might hope that the data would somehow be routed to the capitals table, but this does not happen: INSERT always inserts into exactly the table specified. In some cases it is possible to redirect the insertion using a rule (see Chapter 34). However that does not help for the above case because the cities table does not contain the column state, and so the command will be rejected before the rule can be applied.

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.

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 "merged" 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.

Table inheritance can currently only be defined using the CREATE TABLE statement. The related statement CREATE TABLE AS 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 CASCADE option.

ALTER TABLE 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 CASCADE option. ALTER TABLE follows the same rules for duplicate column merging and rejection that apply during CREATE TABLE.

5.8.1. Caveats

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 ONLY notation. When adding a new child table to an existing inheritance hierarchy, be careful to grant all the needed permissions on it.

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:

  • If we declared cities.name to be UNIQUE or a PRIMARY KEY, this would not stop the capitals table from having rows with names duplicating rows in cities. And those duplicate rows would by default show up in queries from cities. In fact, by default capitals would have no unique constraint at all, and so could contain multiple rows with the same name. You could add a unique constraint to capitals, but this would not prevent duplication compared to cities.

  • Similarly, if we were to specify that cities.name REFERENCES some other table, this constraint would not automatically propagate to capitals. In this case you could work around it by manually adding the same REFERENCES constraint to capitals.

  • Specifying that another table's column REFERENCES cities(name) would allow the other table to contain city names, but not capital names. There is no good workaround for this case.

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.

Deprecated: In previous versions of PostgreSQL, 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 * to the table name. For example:

SELECT * from cities*;

You can still explicitly specify scanning child tables by appending *, as well as explicitly specify not scanning child tables by writing ONLY. 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 sql_inheritance configuration option.

Comments


Nov. 22, 2005, 12:56 p.m.

While it doesn't actually prevent duplicate primary keys entering a child table, I use this to at least make the system work acceptably:
CREATE SEQUENCE seq_city_id INCREMENT 1 START 1;
CREATE TABLE cities (
ID int NOT NULL DEFAULT NextVal('seq_city_id') PRIMARY KEY,
name text,
population float,
altitude int -- in feet
);

CREATE TABLE capitals (
ID int NOT NULL DEFAULT NextVal('seq_city_id') PRIMARY KEY,
state char(2)
) INHERITS (cities);

The primary key constraint is only valid per-table not per-heirarchy, so there is nothing to prevent manual addition of the same primary key to both tables. However, making both the tables use the same sequence for their default does mean that in normal use no conflict will occur and either ID column may be used in a REFERENCES clause from another table.


Dec. 8, 2005, 1:08 a.m.

Nice article about useful aspects of inheritance - for some kind of partitioning in particular at General Bits: "Distributed Indexing with Table Inheritance" [http://www.varlena.com/varlena/GeneralBits/98.php]


May 23, 2006, 12:16 p.m.

Yes but this example isn't interesting because you obtain the same with a sample serial :

CREATE TABLE cities (
id serial,
name text,
population float,
altitude int -- in feet
);

CREATE TABLE capitals (
state char(2)
) INHERITS (cities);

\d cities
id | integer | not null default nextval('public.cities_id_seq'::text)
...

\d capitals
id | integer | not null default nextval('public.cities_id_seq'::text)
...


Sept. 24, 2006, 2:57 a.m.

Just a point of clarification, of course the satement:

INSERT INTO cities (name, population, altitude, state)
VALUES ('New York', NULL, NULL, 'NY');

won't work. New York is NOT the capital of NY. Albany is the capital. :)


Nov. 11, 2006, 10:33 p.m.

"Specifying that another table's column REFERENCES cities(name) would allow the other table to contain city names, but not capital names. There is no good workaround for this case."

Solution to the above would surely be to setup a VIEW that does a query of all cities - including capitals - and use that view in the REFERENCES argument.


June 24, 2007, 11:03 p.m.

There is indeed a difference between Arnaud's code and Andy's, above. In Arnaud's code, he is simply creating a sequence object that is shared by both tables. In Andy Parkins' example, he is creating a sequence object that is shared by both tables AND is creating a primary key index on both tables (individually).

However, we could take Arnaud's code a little further to make it equivalent to Andy's:

CREATE TABLE cities (
id serial,
name text,
population float,
altitude int -- in feet
);

CREATE TABLE capitals (
state char(2)
) INHERITS (cities);

ALTER TABLE cities ADD PRIMARY KEY (id);
ALTER TABLE capitals ADD PRIMARY KEY (id);

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group