On Mon, May 23, 2016 at 10:21 AM, Jim Nasby <jim.na...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers