[HACKERS] Inheritance

2016-05-22 Thread Jan Johansson
Hi,

I've been reading some threads about inheritance, and how complicated it
seems to let child (children) to inherit constraints and indexes
(behaviors). In fact this seems to have been the issue for years, with no
resolution.

However, inheritance is a very good feature, and it would be great to have
it feature complete.

To try to unlock the feature, to be more complete, how about introducing
restriction to inheritance like:

 - 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?

Kind regards,
Jan Johansson


[HACKERS] PostgreSQL and inherits

2016-05-19 Thread Jan Johansson
Hi,

I want to discuss about inherits in PostgreSQL.
Everything I write here is my own opinion, but I hope for a good dialog.

I think that inherits is a feature to good to be plain legacy, but it is
unfortunately riddled with some inconsistencies. The inheritance keyword
link tables together in a "is-a" chain, from child up to parent. The
children has the same fields as the parent, plus their own (if they
declare).

In one way there is an illusion of object orientation, where the children
share data with the parent (comes from when you select from a parent in the
inheritance and you see the data), but in another way if you use the
condition "only" (in select) or discover that field behavior (primary key,
foreign key, etc) is not inherited, then inheritance is of the behavior of
interface.

It's like the implementation sits on the fence, and does not know if
inherits is object oriented, or if it is interface oriented.

This inconsistency makes the feature not as smooth as it could be.

A suggestion would be to walk down the path for the object oriented
approach, meaning that fields shared with the parent, also share behavior
(primary key, foreign key, etc). This suggestion might break compatibility
with some implementations (using inheritance and where coding has been done
to account for the object-interface-oriented approach).

Another suggestion would be to walk down the path for the interface
oriented approach, meaning that nothing is shared between the child and
parent, except for the field name and types. This may also break
compatibility.

The third suggestion would be to let inheritance be as it is, but to
introduce "extends" keyword to make a more clean object-oriented approach
to the "is-a" chain. Then nothing is broken, but it adds complexity to the
schema.

I'd be happy to know your reflections about the subject.

Kind regards