On Mon, May 23, 2016 at 10:21 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 5/22/16 1:37 AM, Jan Johansson wrote:
>>
>> - Allow single (behavior) inheritance (model here is quite a few modern
>> languages, such as C#, D, ...)
>> - Allow multiple declarative inheritance (interface like, the
>> inheritance almost works like this today though)
>>
>> If, with these restrictions (or maybe only the first), do you think that
>> it will simplify implementation and make it more feature complete?
>
> I think you'll need to be a bit more specific to elicit a response. What
> exactly are you proposing to change?
I would guess OP is complaining about what everyone complains about.
What people want is for tables to have a base set of shared columns by
a varying set of derived type dependent columns. Constraints on the
shared columns will be enforced on all the derived columns.
Postgres doesn't work that way, and the documentation disclaims this:
"Note: Although inheritance is frequently useful, it has not been
integrated with unique constraints or foreign keys, which limits its
usefulness. See Section 5.8 for more detail."
Personally, I don't think this will ever be fixed. The reason why it
doesn't work is due to some foundational implementation decisions that
would have to be revisited.
This feature was very much a product of the time, at the height of the
"Object Relational" fad. The trend for postgres has been in the exact
opposite direction, towards the SQL standard. Further complicating
matters, inheritance has been repurposed to be the foundation for
table partitioning, making heavy changes problematic.
The classic SQL approach to the problem, establishing a base table
plus a type and derived tables with a pkey:pkey link isn't a very bad
one from a data modelling perspective and serialization to the
application is increasingly going to be handled by json going forward
as opposed to hacking the postgres type system. This really reduces
the value proposition of heavy changes to the inheritance features.
If there was consensus on that point, I suppose the way forward is
some documentation restructuring, starting with removing the
increasingly baroque tutorial (trivia: the tutorial was the old manual
at one point).
merlin