There is one aspect of inheritance support which was not mentioned: polymorphic queries. Actually polymorphism is the fundamental feature of OOP, without it there is no behavioral inheritance and inheritance can be considered just as "syntax sugar" for sharing some common subset of attributes between tables.

The main problem with supporting polymorphic queries is that SQL query returns set of tuples, not set of objects. So there is no nice way to return both instances of based and derived tables. There are several alternatives (for example return joined set of attributes in all derived tables, leaving missed as NULLs) but none of them is good.

There is more specific problem - polymorphic function calls, see:

which in principle can be solved... But looks like there is no such intention.

I do not know how much people will be interested in normal OO support from DBMS. Right now PostgreQSL inheritance is used for different purposes: partitioning, FDW-based replication or sharding, ... But IMHO it is mostly because current inheritance implementation just not make it possible to use it for OOP. As far as I know before there were a lot of discussions whether arrays, json and other non-traditional for RDBMS types is needed. But right now them are quite popular and frequently used. The same thing can happen with OO support: it will be popular if provide necessary functionality.

Right now OO DBMS applications are mostly using ORMs and them are not using PostgreSQL inheritance. Mostly because ORMs are used to be more flexible in providing different approaches for implementing inheritance (for example in most cases placing all derived classes in single table works better than approach based on appending results of several queries). Another reason is that ORM usually support more than one DBMS, and since most of them have no built-in support for inheritance,
ORM has to implement inheritance itself.
But I do not think that presence of ORM excludes necessity to have internal support of OO in DBMS.

On 24.05.2016 16:51, Jim Nasby wrote:
On 5/23/16 10:30 PM, Craig Ringer wrote:
I find it notable that no popular ORM has bothered adopting PostgreSQL's
inheritance features, and instead just use big left joins or repeated
SELECTs to implement parent/child relationships, with foreign keys
enforcing constraints.

Since when do we consider ORMs to be an example of how to do good database design?

In this case, I'm sure no ORM uses the feature because either the ORM's authors have no clue it exists (except maybe for partitioning) or because we're the only mainstream database that has it.

I consider inheritance mostly useless without the ability to have UNIQUE
indexes that span a parent relation and all its children. You can use
them for partitioning only by sacrificing a bunch of integrity
protection or creating messy chains of FKs between individual partitions.

There's ways around this issue, but I agree that it's a very unhappy situation right now.

I'd rather like to quietly deprecate inheritance and eventually remove
it once we have real partitioning and some time has passed...

IMO that's a very unfortunate attitude to have for the "Worlds Most Advanced Open Source Database". Now that OO programming isn't treated as a magic bullet it's proven to be an extremely powerful tool, especially when used to encapsulate complex data. The ndarray->Series->DataFrame->Panel inheritance tree is a great example of this. Feature-wise, we need to be doing *more* of this kind of work, not less. Lack of support for OO paradigms was one of the drivers for NoSQL.

Konstantin Knizhnik
Postgres Professional:
The Russian Postgres Company

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to