Hacker News Reader

No, i suggest reverse these kinds of advice and DO THIS instead.

Why ?

Because IF it's said not to do this, it should not be implemented in first place.

This is a trap.

For example, "Don't use table inheritance", you should always use this to reuse the table definition. If not, what's the alternative ?

View on HN

> it should not be implemented in first place

Some of it exists for important reasons, that are documented on the page. For example, respecting the SQL standard, or maintaining compatibility with database from a time/system without the replacement feature, or for special circumstances that don't apply to you.

The alternative is to just copy paste the table definition or do composition with foreign keys. Seems like field inheritance was invented only because we are too lazy, I have not seen yet valid cases for inheritance in Postgres or any OOP language.

Until the implementation of declarative partitioning, inheritance was the only way to do table partitioning. Although the partitioning use case has mostly been replaced, that doesn't mean it can just be removed as there are existing systems using inheritance to manage their data.

Reply on news.ycombinator.com