Понятие наследования в PostgreSQL происходит от аналогичного понятия в объектно-ориентированном программировании, однако имеет свои особенности, связанные именно с тем, что мы имеем дело с конкретными таблицами, наполненными конкретными данными.

Допустим, что у нас есть некоторая простая БД, описывающая ассортимент некоторого магазина электроники.
Создадим простую таблицу, описывающую имеющиеся в наличии DVD-плееры.

CREATE TABLE dvd (
	id integer,
	maker varchar, 
	model varchar, 
	price money);

Предположим, что нам нужно создать ещё одну таблицу, в которую будут внесены уже домашние кинотеатры. Так как любой современный домашний кинотеатр заведомо включает в себя DVD-плеер, то получается, что в таблице, описывающей домашние кинотеатры, заведомо должны иметься четыре поля, аналогичные тем, которые характеризуют DVD, плюс поля, специфичные именно для домашних кинотеатров. В нашем случае мы можем ввести поле, в котором будет храниться количество компонент акустики.

Можно попробовать действовать в лоб:

CREATE TABLE home_cinema (
	id integer,
	maker varchar, 
	model varchar, 
	sound integer,
	price money);

Вроде как все отлично. Таким же образом можно создать аналогичные таблицы portable_dvd и car_dvd, описывающие соответственно портативные и автомобильные DVD-плееры. В их составе будут как и общие для всех видов DVD-плееров поля, так и специфичные для каждого типа.

Предположим теперь, что наша БД должна теперь использоваться не только для внутренних нужд самого магазина, теперь она используется для работы интернет-магазина с таким же ассортиментом. Соответственно, в исходной таблице dvd появятся новые поля supported_formats и description, представляющие соответственно битовую маску для описания поддерживаемых плеером форматов и краткую текстовую характеристику модели для потенциального покупателя.
Вот тут и возникает неудобство. Вместо одной таблицы dvd у нас теперь четыре и в каждую нужно вносить изменения. Вроде как ерунда... А если предположить вместо нашей игрушечной БД реальную рабочую с гораздо большим количеством таблиц, полей и содержащихся данных?

Вот теперь на сцену и выходит наследование (inheritance) со всеми его преимуществами и недостатками. Благодаря ему мы можем мы можем объединить нужные нам таблицы в некую иерархию, в которой таблица-потомок будет уже априорно содержать все поля таблицы-предка, без необходимости их явного указания.
Вернемся к тому моменту, когда мы собирались создавать таблицу home_cinema. Сделаем теперь это по-умному, а именно - объявим эту таблицу как потомка таблицы dvd:

CREATE TABLE home_cinema (
	sound integer)
	INHERITS (dvd);

Теперь если мы добавим новые поля к родительской таблице dvd или изменим существующие, то внесенные в её структуру изменения сразу же отразятся на таблице-потомке home_cinema. Аналогичным образом объявляются и две другие таблицы - portable_dvd и car_dvd