You can indeed, but it makes you duplicate every implementation with its associated interface.

As for this kind of relationship, i'd say it's fairly widespread. One proof is that even relationnal DB such as postgresql added table inheritance.

"You can indeed, but it makes you duplicate every implementation with its associated interface."

Only if A: composition can't do the job somehow and B: you can't use perfectly normal factoring tools to do the work.

While I will tell you before anybody else complains that there is a non-zero percentage of the time that will happen, I will also tell you the average person who has never tried Go yet complains about its lack of generics anyhow will overestimate the amount of time that happens by a good order of magnitude or two.

One remark (that may seem like a nitpick, but is in fact crucial) : composition doesn't say it "is a kind of", but rather "it has".

It's the two most fundamental concept of any language : to be vs to have. Now it may or may not be just a philosophical difference and bring no practical consequences to a computer program, but at the minimum one can say it expresses two different concepts.

Table inheritance is merely an optimisation and rarely used.

It's an optimisation against the OOP vs relational mismatch, but the fact that it's here proves that OOP subclassing is being used quite often (otherwise there wouldn't be any need to optimise for it, at least not by adding core features to pg).

All major RDMS offer OOP at table level.