¿Debo agregar una columna de tipo para diseñar la herencia en postgreSQL?

Claro que puede hacer esto, por ejemplo, para hacer cumplir que solo una subtabla puede hacer referencia a una fila determinada:

CREATE TABLE Super_Table (
  super_id SERIAL PRIMARY KEY,
  sub_type CHAR(1) NOT NULL,
  UNIQUE KEY (super_id, sub_type) 
);

CREATE TABLE Sub_Table_A (
  super_id PRIMARY KEY,
  sub_type CHAR(1) NOT NULL,
  CHECK (sub_type = 'A'),
  FOREIGN KEY (super_id, sub_type) REFERENCES Super_Table (super_id, sub_type)
);

CREATE TABLE Sub_Table_B (
  super_id PRIMARY KEY,
  sub_type CHAR(1) NOT NULL,
  CHECK (sub_type = 'B'),
  FOREIGN KEY (super_id, sub_type) REFERENCES Super_Table (super_id, sub_type)
);

Ahora no hay forma de que una fila en ambas subtablas pueda hacer referencia a una fila en Super_Table. La fila en Super_Table debe tener 'A' o 'B', por lo que solo una de las subtablas puede satisfacer la referencia de clave externa.

Re tu comentario:

Tengo entendido que la implementación actual de PostgreSQL de INHERITS permite una serie de anomalías relacionadas con índices, restricciones únicas y restricciones de clave externa. El uso de esta función es complicado y propenso a errores.

Básicamente, debido a que los índices existen solo en una sola tabla, si tiene una restricción única en su tabla principal, ¿cómo puede imponer esa singularidad sobre el padre y todos sus hijos? Los hijos podrían insertar valores en sus tablas que ya existen en el padre, o el padre podría insertar un valor que ya existe en uno de los hijos.

Del mismo modo, las claves foráneas no pueden hacer referencia a la tabla principal y/o a sus elementos secundarios porque es ambiguo a qué fila se hace referencia si pueden existir varias filas en elementos principales/secundarios con la misma clave principal o valor único.

Estas son limitaciones conocidas y no resueltas de INHERITS en PostgreSQL. El diseño que mostré arriba resuelve el problema de la clave principal, pero no de las claves únicas secundarias.

http://archives.postgresql.org/pgsql-hackers/2010 -05/msg00285.php