Let's create two classes. The capitals class contains state capitals which are also cities. Naturally, the capitals class should inherit from cities. CREATE TABLE cities ( name text, population float, altitude int -- (in ft) ); CREATE TABLE capitals ( state char(2) ) INHERITS (cities); In this case, an instance of capitals inherits all attributes (name, population, and altitude) from its parent, cities. The type of the attribute name is text, a native Postgres type for variable length ASCII strings. The type of the attribute population is float, a native Postgres type for double precision floating point numbers. State capitals have an extra attribute, state, that shows their state. In Postgres, a class can inherit from zero or more other classes, and a query can reference either all instances of a class or all instances of a class plus all of its descendants. The inheritance hierarchy is a actually a directed acyclic graph. 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; which 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 of 500ft or higher: SELECT name, altitude FROM ONLY cities WHERE altitude > 500; +----------+----------+ |name | altitude | +----------+----------+ |Las Vegas | 2174 | +----------+----------+ |Mariposa | 1953 | +----------+----------+ Here the ONLY before cities indicates that the query should be run over only cities and not classes below cities in the inheritance hierarchy. Many of the commands that we have already discussed -- SELECT, UPDATE and DELETE -- support this ONLY notation. In some cases you may wish to know which table a particular tuple originated from. There is a system attribute 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 | +---------+----------+----------+ |37292 |Las Vegas | 2174 | +---------+----------+----------+ |37280 |Mariposa | 1953 | +---------+----------+----------+ |37280 |Madison | 845 | +---------+----------+----------+ If you do a join with pg_class you can see the actual table name: 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 | +---------+----------+----------+ |capitals |Las Vegas | 2174 | +---------+----------+----------+ |cities |Mariposa | 1953 | +---------+----------+----------+ |cities |Madison | 845 | +---------+----------+----------+ In previous versions of Postgres, the default was not to get access to child tables. This was found to be error prone and is also in violation of SQL99. Under the old syntax, to get the sub-classes 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, set the configuration option SQL_Inheritance to off, e.g., SET SQL_Inheritance TO OFF; or add a line in your postgresql.conf file.