Re: Inheritance

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:

http://postgresql.nabble.com/Polymorphic-function-calls-td5784772.html

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: http://www.postgrespro.com
The Russian Postgres Company