| The article seems to misunderstand what table inheritance is in PostgreSQL. CREATE TABLE new_table AS TABLE existing_table; Doesn't create any PostgreSQL inheritance relationship between the parent and child tables. It merely makes a new non-inherited table with a copy of the data whereas with true table inheritance you're working with the same data (there's some visibility rules to consider between parent and child, but that's different than a copy). I'm also uncomfortable with too simply stating that you should think of this like OOP inheritance; while I agree that in some respects there's passing similarity, it is its own beast and needs to be understood outside of the OOP paradigm to be useful. Many of the Object Relational aspects of PostgreSQL are very powerful, but can not be understood in OOP terms. For inheritance, it's better to read about this from the documentation: https://www.postgresql.org/docs/12/tutorial-inheritance.html Also, another part of the article talks about the ramifications of not having Oracle "packages". So while it's not completely the same concept and there are different sets of trade-offs, one option includes using PostgreSQL schema for this sort of logical namespace organization. Both Oracle and PostgreSQL have the concept of different schemas, but Oracle has a much more rigid idea about schema usage (related to database users) and PostgreSQL has a much more fluid idea about usage. As a former Oracle guy, I can see how that organizational tool might not be front of mind when coming to PostgreSQL, but I've used PostgreSQL schema for this sort of organizational purpose with good success. |