From the Postges site:

"A 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. Thus, in the above
example, specifying that another table's column REFERENCES cities
(name) would allow the other table to contain city names but not
capital names. This deficiency will probably be fixed in some future
release."

A fairly major deficiency! However, I do like the way Postgres uses
arrays to achieve object-based SQL.

Arguably, the whole inheritance issue is a natural part of relational
db design anyway; and being based on 'directional acyclic graphs' is
achievable with a 'parent' field with self-referencing of records
denied.

This is IBDI fodder, though.

Regards,
Andrew Ferguson
-- I know what's best for you but I'm not telling.

--- In ib-support@y..., "Raul Chirea" <raul_chirea@l...> wrote:
> Hi,
>
> I can see that you don't know much about Postgres model of table
> inheritance.
> This model does not break in any way data integrity or relational
model.
> Primary key _instance_ is the same for the base table and it's
derived
> tables. When you select from a table the results will include
_child_tables_
> also. This is a very interesting feature because you can enforce
uniqueness
> to more than one table, like this:
>
> create table docs (
> id integer not null,
> title varchar(128),
> body_text varchar(16000),
> primary key (id)
> );
>
> create table docs_with_header (
> header varchar(16000)
> ) inherites (docs);
>
> create table docs_with_footer (
> footer varchar(16000)
> ) inherits (docs);
>
> After that you can select:
>
> select id, title from docs; -- will give all docs including child
tables
> select id, title from only docs; -- will give docs in table "docs"
only
> select id, title, header, body_text from docs_with_header; -- will
give rows
> in "docs_with_header" table
>
> ... and so on !
>
> I agree that this type of inheritance is not needed too often but
sometimes
> is very usefull ! It can be substituted with classic RDBMS
techniques but it
> nice to have it !
>
> Raul.