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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
